Redis 7: streams для event-driven backend

Практический гайд по использованию Redis Streams (по состоянию на 2026) для построения event-driven backend. Примерные шаги можно выполнить за 45–90 минут на машине с 2 ГБ ОЗУ.

Что вы изучите

• Как записать и прочитать события в Redis Streams с помощью XADD и XREAD.
• Как настроить группы потребителей (consumer groups) и обеспечить параллельную обработку с помощью XGROUP и XREADGROUP.
• Механизмы подтверждений (acknowledgments) через XACK, работа с pending list и повторная обработка.
• Как управлять размером стрима (trimming), мониторить состояние и отлаживать с XINFO и XPENDING.
• Отличия Redis Streams от Kafka и практические рекомендации, когда выбрать Redis, а когда Kafka.

Требования

• Redis 7.x (в статье тестирование по состоянию на март 2026 проводилось на Redis 7.2.1, сборки 2025–11). Порт по умолчанию: 6379.
• redis-cli/redis-tools совместимые с 7.x. Образ Docker: redis:7 (сжатый размер ~32 MB, распакованный ~60 MB, запуск контейнера ~200–500 ms).
• Минимальные ресурсы для локальной отладки: 512 MB ОЗУ, 1 vCPU. Рекомендуемые для production: 2–8 GB ОЗУ, 2+ vCPU.
• Примеры приведены для Linux (Ubuntu 22.04/24.04) и Docker 24.x. Время выполнения каждого шага 1–20 минут в зависимости от окружения.
• Потребуется знание базовых команд Redis и умение запускать контейнеры Docker. Для CI/CD и деплоя полезны навыки из DevOps и понимание работы с Базы данных.

Зачем Redis Streams?

Redis Streams — встроенный в Redis тип данных, появившийся в Redis 5 и активно развиваемый в ветке 7.x. По состоянию на 2026 Streams остаются легковесным вариантом для реализации event-driven архитектур, где важна низкая задержка, простота деплоя и оперативная обработка сообщений. Streams хорошо подходят для уведомлений, очередей задач, синхронизации между сервисами и временных логов с коротким временем хранения.

Главные преимущества: простота настройки (Redis single binary, порт 6379), низкая латентность (<1 ms в локальной сети), и встроенные primitives для consumer groups, ack и повторной доставки. Ограничения: хранение в памяти (хотя есть опции виртуализации), отсутствие нативной партиционизации как у Kafka и модели длительного хранения больших объемов данных. В статье представлены практические команды и типовые ошибки, которые вы встретите при переходе к event-driven модели на Redis Streams.

Шаг 1: XADD и XREAD

Цель: научиться записывать события в stream и читать их простым способом. Команды приведены для redis-cli и Docker-окружения.

Команда (запись события):

redis-cli XADD mystream * event_type login user_id 42 timestamp 2026-03-01T12:00:00Z

Объяснение: XADD добавляет запись в stream mystream. Символ * просит Redis сгенерировать ID на основе текущего времени. Поля передаются как пары ключ/значение: event_type, user_id, timestamp.

Ожидаемый успешный вывод (пример):

"1710000000000-0"

Пояснение вывода: ID формата UNIX-milliseconds-seq. В примере ID начинается с миллисекунд; значение будет отличаться в вашем окружении (время выполнения ~ <1 ms).

Типичная ошибка и как её фиксить:

(error) ERR wrong number of arguments for 'xadd' command

Причина: нечетное количество аргументов после ключа; поля должны идти парами ключ/значение. Фикс: проверить команду и добавить/удалить поле, чтобы пары соответствовали.

Чтение событий (негрупповое):

redis-cli XREAD COUNT 10 STREAMS mystream 0

Объяснение: XREAD читает новые элементы. Параметр COUNT ограничивает число возвращаемых записей. Последний аргумент 0 означает чтение от начала стрима; для чтения только новых событий используйте $.

Ожидаемый вывод (пример):

1) 1) "mystream"
   2) 1) 1) "1710000000000-0"
         2) 1) "event_type"
            2) "login"
            3) "user_id"
            4) "42"
            5) "timestamp"
            6) "2026-03-01T12:00:00Z"

Типичная ошибка и фикс:

(nil)

Причина: пустой ответ — нет данных в выбранном диапазоне. Фикс: проверьте правильность ID (вместо 0 используйте - для диапазона) или используйте XREAD BLOCK 1000 STREAMS mystream $ для блокирующего ожидания новых событий.

Шаг 2: consumer groups

Цель: создать consumer group и прочитать события несколькими потребителями параллельно, используя XGROUP и XREADGROUP.

Создание группы (если стрим отсутствует — флаг MKSTREAM создаст его):

redis-cli XGROUP CREATE mystream mygroup $ MKSTREAM

Объяснение: создаем группу mygroup для стрима mystream. Параметр $ означает, что группа начнет читать только новые сообщения, появившиеся после создания. MKSTREAM создаст stream, если его нет.

Ожидаемый вывод:

OK

Типичная ошибка и фикс:

(error) BUSYGROUP Consumer Group name already exists

Причина: группа уже создана. Фикс: удалить группу командой XGROUP DESTROY mystream mygroup или использовать XGROUP SETID для изменения позиции.

Чтение из группы (пример для потребителя consumer-1):

redis-cli XREADGROUP GROUP mygroup consumer-1 COUNT 5 BLOCK 2000 STREAMS mystream >

Объяснение: XREADGROUP читает сообщения от имени группы. Специальный ID > означает только новые сообщения, назначенные группе впервые. BLOCK 2000 ставит таймаут 2000 ms на ожидание.

Ожидаемый успешный вывод:

1) 1) "mystream"
   2) 1) 1) "1710000001234-0"
         2) 1) "event_type"
            2) "login"
            3) "user_id"
            4) "43"
            5) "timestamp"
            6) "2026-03-01T12:05:00Z"

Типичная ошибка и фикс:

(error) NOGROUP No such key 'mystream' or consumer group 'mygroup'

Причина: либо стрим отсутствует, либо группа не создана. Фикс: проверить существование стрима (EXISTS mystream) и создать группу с MKSTREAM.

Шаг 3: acknowledgments

Цель: изучить подтверждения обработки сообщений, управление pending list и повторную доставку.

Подтверждение обработанного сообщения:

redis-cli XACK mystream mygroup 1710000001234-0

Объяснение: XACK удаляет ID из pending list группы. Возвращает количество подтвержденных сообщений.

Ожидаемый вывод (пример):

(integer) 1

Типичная ошибка и фикс:

(integer) 0

Причина: возвращено 0 — указанный ID не найден в pending list для группы. Фикс: убедитесь, что ID корректен и принадлежал группе. Смотрите список незавершенных через XPENDING и повторно назначайте с помощью XCLAIM при необходимости.

Просмотр pending list и статистики:

redis-cli XPENDING mystream mygroup
redis-cli XINFO GROUPS mystream
redis-cli XINFO CONSUMERS mystream mygroup

Примеры ожидаемого вывода:

1) (integer) 5                  # общее число сообщений в PEL (pending entries list)
2) "1710000001000-0"
3) "1710000002000-0"
4) 1) 1) "consumer-1"
      2) (integer) 3
      3) (integer) 0
      4) (integer) 0

Повторная обработка несделанных сообщений (XCLAIM):

redis-cli XCLAIM mystream mygroup new-consumer 60000 1710000001000-0 IDLE 3600000

Объяснение: XCLAIM позволяет перекласть владение над сообщением другому потребителю; параметр в миллисекундах задает минимальное время простоя (IDLE), после которого можно забирать сообщение. Use-case: consumer упал, нужно вернуть задания в работу.

Типичная ошибка и фикc:

(error) ERR No such consumer

Причина: указанный consumer отсутствует. Фикс: создать consumer через чтение XREADGROUP или использовать корректное имя consumer в XCLAIM.

Шаг 4: trimming и capping

Цель: контролировать размер стрима, чтобы не переполнять память Redis. Покажем параметры XTRIM и MAXLEN.

Команда для мягкого ограничения длины (approximate trimming):

redis-cli XTRIM mystream MAXLEN ~ 10000

Объяснение: MAXLEN ~ N оставляет около N последних записей, используя быстрый approximate алгоритм. Тильда (~) делает операцию быстрее, но менее точной. Выполнение команды обычно занимает миллисекунды, зависящее от объема удаляемых записей.

Ожидаемый вывод:

(integer) 9500

Пояснение: возвращает число удалённых записей (примерное значение). Уточнение: точное число зависит от операций и состояния памяти.

Строгое ограничение (медленнее, точное):

redis-cli XTRIM mystream MAXLEN = 10000

Ошибка и фикс:

(error) ERR syntax error

Причина: синтаксическая ошибка в использовании аргументов. Фикс: проверьте порядок аргументов и используйте либо ~, либо =, либо без модификаторов.

Советы по размерам: на 1 запись с 3 полями по 64 байта средний расход ОЗУ ~ 1 KB. Значит 10k записей ≈ 10 MB. На production задавайте лимиты с запасом и мониторьте used_memory в Redis INFO.

Шаг 5: мониторинг и отладка

Цель: научиться получать ключевую телеметрию по streams и группам, находить «зависшие» сообщения и измерять задержки.

Команды для диагностики:

redis-cli XINFO STREAM mystream
redis-cli XINFO GROUPS mystream
redis-cli XPENDING mystream mygroup
redis-cli XRANGE mystream - + COUNT 10

Ожидаемый вывод (фрагменты):

1) "length"
2) (integer) 12345
3) "first-entry"
4) 1) "1710000000000-0"
   2) 1) "event_type"
      2) "login"
... 
# XPENDING summary
1) (integer) 12    # total pending
2) "1710000001000-0"
3) "1710000002000-0"
4) 1) 1) "consumer-1"
      2) (integer) 6

Типичная проблема: растущая очередь pending (XPENDING показывает много записей) и низкая скорость XACK. Причины: потребители тормозят, long processing, deadlock или GC в runtime. Фикс: масштабируйте число потребителей, увеличьте parallelism, профилируйте обработчик и используйте XCLAIM для восстановления заданий.

Метрики и SLA: измеряйте время от генерации события до XACK. Цель для real-time уведомлений — p50 < 50 ms, p95 < 200 ms в локальной сети; в облаке и при нагрузке значения будут выше. Для фоновых задач допустим p95 до нескольких секунд.

Какие отличия от Kafka?

Сравнение основных характеристик по состоянию на 2026, с цифрами для практического выбора:

• Архитектура: Kafka — распределённая система с партиционированием и репликацией на диск, ориентированная на длительное хранение и высокую пропускную способность. Redis Streams — тип данных in-memory с опциями сохранения на диск (AOF/RDB) и упором на скорость и простоту.
• Долговременное хранение: Kafka легко хранит терабайты на дисках с retention policy, Redis ограничен оперативной памятью. Пример: на 1 миллион сообщений среднего размера 1 KB Redis потребует ~1 GB ОЗУ; Kafka при том же объёме хранит данные на диске, требуя минимум десятки гигабайт дискового пространства.
• Параллелизм и партиции: Kafka использует партиции для масштабирования обработки. В Redis Streams масштаб достигается через отдельные streams или шардирование инстансов. Для горизонтального масштабирования Redis требует внешней шардовой архитектуры (Redis Cluster) и ручной организации consumer groups.
• Гарантии доставки: Kafka обеспечивает at-least-once по умолчанию и опционально exactly-once через транзакции; Redis Streams обеспечивает at-least-once, повторная доставка и механизмы XACK/XCLAIM для управления. Exactly-once в Redis требует дополнительной логики на уровне приложения.
• Производительность: Redis даёт меньшую латентность (типично <1 ms на локальной сети), Kafka обеспечивает большую пропускную способность при длительном хранении и batch-ориентированной обработке (сотни тысяч сообщений в секунду на кластер).

Коротко: используйте Redis Streams для low-latency, простых event-driven задач (уведомления, синхронизация, очереди задач), Kafka — для больших потоков данных, длительного хранения и сложной обработки в масштабах нескольких дата-центров.

Когда использовать?

Выбор между Redis Streams и альтернативами зависит от требований к задержке, объёму хранения и устойчивости:

• Используйте Redis Streams, если нужно: низкая латентность, простой деплой (один бинарный файл), быстрая разработка и небольшие/средние объёмы событий (десятки тысяч/минуту), оперативная обработка и возможность контроля памяти через XTRIM. Минимальная инфраструктура: один экземпляр Redis или кластер; рекомендуемые ресурсы для production: 4 GB ОЗУ и 2 vCPU для средней нагрузки.
• Выберите Kafka, если требуются: долговременное хранение терабайтов данных, упор на throughput и partition-based parallelism, сложные гарантии доставки и интеграция с ecosystem (Kafka Connect, ksqlDB). Kafka требует более серьёзного операционного сопровождения и дискового пространства.
• Комбинация: часто Redis действует как фронт для latency-sensitive обработки, а Kafka или object store — как долговременное хранилище. События можно дублировать: быстрый путь через Redis для real-time, копия в Kafka для аналитики и долгого хранения.

Частые вопросы

Как обеспечить exactly-once delivery с Redis Streams?

Exactly-once не реализуется «из коробки» в Redis Streams так же, как в Kafka с транзакциями. Достичь эффекта exactly-once можно комбинацией idempotent-обработки на уровне приложения, хранения состояния результата обработки (например в PostgreSQL с уникальным ключом по event_id) и аккуратного использования XACK только после коммита результата. Типовой паттерн: consumer читает событие, проверяет, не обработано ли оно (lookup по event_id), выполняет обработку и только после успешного коммита делает XACK. При рестарте consumers используют XPENDING и XCLAIM для восстановления непотверждённых задач.

Что делать, если Redis потребляет слишком много памяти из-за streams?

Первое — настроить trimming: XTRIM с MAXLEN или периодическая агрегация старых событий в внешнее хранилище (S3/диск/Kafka). Мониторьте used_memory в INFO и установите алерты. Если требуется долговременное хранение больших объёмов, держите Redis как буфер/обработчик и экспортируйте архивы событий в Kafka или object storage. Для production учитывайте настройку vm.overcommit и AOF configuration, чтобы избежать нестабильности при нехватке памяти.

Где лучше хранить offset/position — в Redis или в приложении?

Redis Streams хранит позицию чтения внутри consumer group — это удобно, потому что оффсеты управляются на стороне Redis и доступны всем потребителям группы. Если вы строите кастомный механизм, можно хранить позицию в приложении или в базе данных для специфических сценариев восстановления. Для стандартных сценариев используйте встроенные consumer groups: это упрощает failover, XINFO и XPENDING дают готовую телеметрию.

Сколько потребителей может обслуживать одна consumer group?

Теоретически число потребителей в группе не ограничено, но практическая эффективность зависит от нагрузки и объема сообщений. Для небольших стримов десятки потребителей работают нормально. При сотнях потребителей начинаются накладные расходы на coordination и PEL. Если нужно масштабировать — используйте несколько групп или шардируйте стримы по ключам (например, user_id % N). Всегда мониторьте метрики: задержки, размер pending list и throughput.

Чем отличается Redis Streams от простых списков (LPUSH/RPOP)?

Streams сохраняют ID, поддерживают чтение по диапазонам, consumer groups и pending list для надёжной доставки. LPUSH/RPOP — простая очередь без групп и без трекинга подтверждений. Для конкурентных обработчиков и гарантий повторной доставки Streams предпочтительнее. LPUSH/RPOP подойдут для простых FIFO очередей с быстрым потреблением, но без продвинутого управления отказами.