Redis Streams против Kafka Streams/NATS

Question

Команда Redis представляет новый тип данных Streams для Redis 5.0. Поскольку Streams с первого взгляда выглядит как темы Kafka, странно находить реальные примеры его использования.

В представлении потоков у нас есть сравнение с потоками Кафки:

1. Обработка групп потребителей во время выполнения. Например, если один из трех клиентов потерпит неудачу навсегда, Redis продолжит обслуживать первое и второе, потому что теперь у нас будет только два логических раздела (потребителей).
2. Redis потоков намного быстрее. Они хранятся и работают из памяти, так что это как есть.

У нас есть проект с Kafka, RabbitMq и NATS. Теперь мы углубимся в поток Redis, чтобы попытаться использовать его в качестве "кэша pre kafka", а в некоторых случаях в качестве альтернативы Kafka/NATS. Самым критическим моментом сейчас является репликация:

1. Сохраните все данные в памяти с репликацией AOF.
2. По умолчанию асинхронная репликация не гарантирует, что изменения состояния команд XADD или групп потребителей будут реплицированы: после аварийного переключения что-то может отсутствовать в зависимости от способности ведомых устройств получать данные от мастера. Это похоже на точку, чтобы убить любой интерес, чтобы попробовать потоки в высокой нагрузке.
3. Процесс восстановления после сбоя Redis, выполняемый Sentinel или Redis Cluster, выполняет только наилучшую проверку для переключения на ведомое устройство, которое является наиболее обновленным, и при определенных конкретных сбоях может выдавать ведомое устройство, которому не хватает некоторых данных.

И стратегия кепки. Настоящим "ограниченным ресурсом" в Redis Streams является память, поэтому на самом деле не так важно, сколько элементов вы хотите сохранить или какую стратегию ограниченного использования вы используете. Таким образом, каждый раз, когда ваш потребитель терпит неудачу, вы получите пиковое количество памяти или потерянные сообщения с заглушкой.

Мы используем Kafka в качестве клиентского интерфейса RTB, который обрабатывает ~1 100000 сообщений в секунду с полезной нагрузкой ~120 байт. С Redis мы имеем ~170 МБ / с потребления памяти при записи, а с 512 ГБ ОЗУ сервера мы имеем "резерв" записи на ~50 минут данных. Таким образом, если бы система обработки была бы отключена в это время, мы бы потерпели крах

Не могли бы вы рассказать подробнее об использовании Redis Streams в реальном мире, и, возможно, в некоторых случаях вы пытаетесь использовать его самостоятельно? Или может быть Redis Streams можно использовать с небольшим объемом данных?

Answer 1

Давно не виделись. Это похоже на обсуждение, которое входит в список рассылки redis-db, но сценарий использования звучит увлекательно.

Обратите внимание, что Redis Streams не предназначены для замены Kafka - они предоставляют различные свойства и возможности, несмотря на сходства. Вы, конечно, правы в отношении асинхронного характера репликации. Что касается масштабирования объема доступной оперативной памяти, вы должны рассмотреть возможность использования кластера и разделить ваши потоки по именам ключей на основе периодов.