В этой части исследуются варианты использования, мотивы и дается общий обзор функций Redis, используемых в решении.

Добро пожаловать в эту серию сообщений в блоге, в которых рассказывается о Redis Streams с помощью практического примера. Мы будем использовать образец приложения, чтобы сделать данные Twitter доступными для поиска и запросов в режиме реального времени. RediSearch и Redis Streams служат основой этого решения, которое состоит из нескольких взаимодействующих компонентов, каждый из которых мы рассмотрим в отдельном сообщении в блоге.

Код доступен в этом репозитории GitHub - https://github.com/abhirockzz/redis-streams-in-action

Это первая часть, которая исследует вариант использования, мотивацию и предоставляет общий обзор функций Redis, используемых в решении.

Архитектура решения

Вариант использования относительно прост. В качестве конечной цели мы хотим иметь службу, которая позволяет нам искать твиты на основе некоторых критериев, таких как хэштеги, пользователь, местоположение и т. Д. Конечно, для этого есть существующие решения. Сценарий, представленный в этой серии блогов, представляет собой примерный сценарий, который может быть применен к аналогичным проблемам.

Вот краткое описание отдельных компонентов:

  1. Потребитель Twitter Stream: приложение Rust для использования потоковых данных Twitter и передачи их в Redis Streams. Я продемонстрирую, как запустить это как контейнер Docker в Экземплярах контейнера Azure.
  2. Обработчик твитов: твиты из Redis Streams обрабатываются приложением Java - оно также будет развернуто (и масштабировано) с использованием экземпляров контейнера Azure.
  3. Служба мониторинга: последняя часть - это приложение Go для отслеживания прогресса службы обработки твитов и обеспечения повторной обработки любых неудачных записей. Это бессерверный компонент, который будет развернут в Функциях Azure, где вы сможете запускать его на основе триггера таймера и платить только за то время, в течение которого он работает.

Я использовал несколько служб Azure (в том числе Корпоративный уровень кэша Azure для Redis, который поддерживает модули Redis, такие как RediSearch, RedisTimeSeries и Redis Bloom) для запуска различных частей решения, но вы можете немного изменить инструкции и применить их в соответствии с вашей средой, например вы можете использовать Docker, чтобы запускать все локально! Хотя отдельные службы были написаны на разных языках программирования, применяются одни и те же концепции (с точки зрения Redis Streams, RediSearch, масштабируемости и т. Д.) И могут быть реализованы на любом языке по вашему выбору.

«Потребность в масштабе»

Я написал сообщение в блоге RediSearch in Action, в котором описывается тот же вариант использования, то есть как реализовать набор приложений для потребления твитов в реальном времени, индексировать их в RediSearch и запрашивать их с помощью REST API. Однако представленное здесь решение было реализовано с помощью Redis Streams вместе с другими компонентами, чтобы сделать архитектуру масштабируемой и отказоустойчивой. В этом конкретном примере это возможность обрабатывать большой объем твитов, но та же идея может быть расширена / применена к другим вариантам использования, которые имеют дело с высокоскоростными данными, например Интернет вещей, аналитика журналов и т. Д. Для решения таких проблем нужна архитектура, в которой вы можете горизонтально масштабировать свои приложения для обработки растущих объемов данных. Обычно это включает внедрение системы обмена сообщениями, которая действует как буфер между производителями и потребителями. Поскольку это обычное требование и проблемное пространство хорошо изучено, в мире распределенного обмена сообщениями существует множество устоявшихся решений, начиная от JMS (Java Messaging Service), Apache Kafka, RabbitMQ, NATS и, конечно, Redis.

В Redis много возможностей!

Однако в Redis есть что-то уникальное. С точки зрения обмена сообщениями Redis довольно гибок, поскольку предоставляет несколько вариантов для поддержки разных парадигм и, следовательно, обслуживает широкий спектр вариантов использования. Его функции включают Pub-Sub, Lists (подход с очередью рабочих) и Redis Streams. Поскольку эта серия блогов посвящена Redis Streams, я кратко рассмотрю другие возможности, прежде чем двигаться дальше.

  • Pub-Sub: он следует парадигме широковещательной рассылки, когда несколько получателей могут принимать сообщения, отправленные на определенный канал. Производители и потребители полностью разделены, но обратите внимание, что не существует никакой концепции сохранения сообщений, т.е. если приложение-потребитель не запущено и не работает, оно не получает эти сообщения, когда оно возвращается позже.
  • Списки: они позволяют нам применять подход на основе рабочих очередей, который может распределять нагрузку между рабочими приложениями. сообщения удаляются после их использования. он может обеспечить некоторый уровень отказоустойчивости и надежности, используя RPOPLPUSH (и BRPOPLPUSH)

Redis Streams

Redis Streams, представленный в Redis 5.0, обеспечивает лучшее из Pub / Sub и Lists, а также надежный обмен сообщениями, надежность воспроизведения сообщений, группы потребителей для балансировки нагрузки, список ожидающих входа для мониторинга и многое другое! Что отличает его, так это то, что это структура данных append-only log. Вкратце, производители могут добавлять записи (с помощью XADD), потребители могут подписываться на новые элементы, поступающие в поток (с XREAD). Он поддерживает запросы диапазона (XRANGE и т. Д.), А благодаря группам потребителей группа приложений может распределять нагрузку обработки (XREADGROUP) и отслеживать ее состояние (XPENDING и т. Д.).

Поскольку магия Redis заключается в его мощной системе команд, давайте рассмотрим некоторые команды Redis Streams, сгруппированные по функциям для облегчения понимания:

Добавить записи

Есть только один способ добавить сообщения в поток Redis. XADD добавляет указанную запись потока в поток по указанному ключу. Если ключ не существует, в качестве побочного эффекта выполнения этой команды создается ключ со значением потока.

Прочитать записи

  • XRANGE возвращает записи потока, соответствующие заданному диапазону идентификаторов (специальные идентификаторы - и + означают соответственно минимальный возможный идентификатор и максимальный возможный идентификатор внутри потока)
  • XREVRANGE точно так же, как XRANGE, но с той разницей, что записи возвращаются в обратном порядке (сначала используйте конечный идентификатор, а потом начальный идентификатор)
  • XREAD считывает данные из одного или нескольких потоков, возвращая только записи с идентификатором, превышающим последний полученный идентификатор, сообщенный вызывающей стороной.
  • XREADGROUP - это специальная версия команды XREAD с поддержкой групп потребителей. Вы можете создавать группы клиентов, которые потребляют разные части сообщений, поступающих в данном потоке.

Управление потоками Redis

  • XACK удаляет одно или несколько сообщений из списка ожидающих записей (PEL) группы потребителей потока.
  • XGROUP используется для управления группами потребителей, связанными с потоком Redis.
  • XPENDING используется для проверки списка ожидающих сообщений для наблюдения и понимания того, что происходит с группами потребителей потоков.
  • XCLAIM используется для получения права собственности на сообщение и продолжения обработки.
  • XAUTOCLIAM передает право собственности на записи ожидающего потока, соответствующие указанным критериям. Концептуально XAUTOCLAIM эквивалентно вызову XPENDING, а затем XCLAIM

Удалить

  • XDEL удаляет указанные записи из потока и возвращает количество удаленных записей, которое может отличаться от количества идентификаторов, переданных команде в случае, если определенные идентификаторы не существуют.
  • XTRIM обрезает поток, удаляя старые записи (записи с меньшими идентификаторами), если это необходимо.

Для получения подробной информации я настоятельно рекомендую прочитать Введение в Redis Streams (из официальной документации Redis).

А что насчет RediSearch?

Redis имеет универсальный набор структур данных, начиная от простых строк и заканчивая мощными абстракциями, такими как потоки Redis. Собственные типы данных могут занять много времени, но есть определенные варианты использования, которые могут потребовать обходного пути. Одним из примеров является требование использовать вторичные индексы в Redis, чтобы выйти за рамки поиска / поиска на основе ключей для более широких возможностей запросов. Хотя вы можете использовать Сортированные наборы, списки и т. Д. Для выполнения работы, вам придется учесть некоторые компромиссы.

Доступный в виде модуля Redis, RediSearch обеспечивает гибкие возможности поиска благодаря первоклассной системе вторичного индексирования. Некоторые из его ключевых функций включают полнотекстовый поиск, автозаполнение и географическое индексирование. Есть множество других функций, подробное изучение которых выходит за рамки этой серии блогов. Я настоятельно рекомендую вам просмотреть документацию для дальнейшего изучения. А пока вот краткий обзор некоторых RediSearch команд. Вы увидите их в действии в последующих сообщениях блога.

Две из наиболее важных команд включают создание индекса и выполнение поисковых запросов:

  • FT.CREATE используется для создания индекса с заданной схемой и соответствующими деталями.
  • FT.SEARCH выполняет поиск по индексу с помощью текстового запроса, возвращая либо документы, либо просто идентификаторы.

Вы можете выполнять другие операции с индексами:

  • FT.DROPINDEX удаляет индекс. Обратите внимание, что по умолчанию он не удаляет хэши документов, связанные с индексом.
  • FT.INFO возвращает информацию и статистику по индексу, такую ​​как количество документов, количество отдельных терминов и многое другое.
  • FT.ALTER SCHEMA ADD добавляет в индекс новое поле. Это заставляет будущие обновления документов использовать новое поле при индексировании и повторном индексировании существующих документов.

Для работы с функциями автозаполнения вы можете использовать «предложения»:

  • FT.SUGADD добавляет строку предложения в словарь предложений автозаполнения.
  • FT.SUGGET получает предложения завершения для префикса.

RediSearch поддерживает синонимы, представляющие собой структуру данных, состоящую из набора групп, каждая из которых содержит термины-синонимы. FT.SYNUPDATE можно использовать для создания или обновления группы синонимов с дополнительными терминами.

Если вы хотите исправить проверку орфографии в запросе (аналогично функции вы имели в виду), вы можете использовать FT.SPELLCHECK, который выполняет исправление орфографии в запросе, возвращая предложения для терминов с ошибками.

Словарь - это набор терминов. Словари можно использовать для изменения поведения исправления орфографии в запросе RediSearch путем включения или исключения их содержимого из возможных предложений по исправлению орфографии. Вы можете использовать FT.DICTADD и FT.DICTDEL для добавления и удаления терминов соответственно.

Вот и все!

Смотря вперед…

Как я уже упоминал, это было просто знакомство. В течение следующих трех публикаций в блоге вы узнаете подробности об отдельных компонентах, используемых для создания решения. Вы развернете, запустите и проверите их в Azure, а также пройдетесь по коду, чтобы лучше понять, что происходит «за кулисами». Будьте на связи!