Стоит ли использовать Redis как брокер сообщений?

Question

[VladimirKrasnov]

Привет, добрался до изучения брокеров сообщений. Познакомился\попрактиковался с RabbitMQ и kafk'ой и узнал что Redis тоже может быть брокером сообщений. Стоит ли его использовать как брокер? Мб какие нибудь пакеты есть для php\laravel?

Answer 1

[Сергей Соколов]

У Redis есть две возможности, имеющие отношение к «сообщениям»:

1. Pub/Sub – паттерн «издатели/подписчики» – сообщение сразу же, как отправили, доставляется всем подписчикам
   
2. Lists – списки – просто структура данных в памяти. В «хвост» добавляются новые задачу, рабочие разбирают задачи из «головы».
   

Redis Pub/Sub – это доставка сообщений в (почти) реальном времени, но никак не очередь сообщений. Пропустили сообщение, не приняли, подписались позже — не в курсе того, что было. Laravel, разумеется, работает с Redis PubSub.

Redis Lists можно использовать как хранилище для очередей задач – с командой блокирующего чтения (напр. BLPOP) это больше похоже на *.MessageQueue. См. очереди в Laravel. Команда Redis BLPOP – блокирующая, ждёт появления в списке нового элемента и эксклюзивно его выхватывает. Можно несколько «рабочих» процессов подвесить к одному Redis'у. Будут висеть и ждать появления задач. Кто-то из них получит очередную задачу и займётся её обработкой.

Comments

[Иван Шумов]

А с чего это взято что топология как-то связана с персистенцией?) Есть 2 топологии: брокер и медиатор. А что до Redis PubSub, ну так это очень частный случай просто. И не всем подходит

[Сергей Соколов]

Иван Шумов, «ничего не понятно, но очень интересно»

Как вы хотите помочь ТС с его вопросом?

[Иван Шумов]

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

[Сергей Соколов]

Иван Шумов, прекрасно, а ТС'у что-то ответите?

Answer 2

[Илья]

Стоит ли его использовать как брокер?

Я бы рассматривал 2 варианта:
1) Pub/Sub (о нем уже писали выше) - он особо ничего не гарантирует и не хранит сообщения, если в моменте подписчику не удалось его получить, то уже никогда и не удастся.
2) Redis Streams (начиная с версии 5.0) это уже ближе к брокерам сообщений, но не полноценный, а скорее набор команд из которых вы можете собрать свой брокер сообщений. Заявлена некая персистентность за счет репликации между репликами, дампов данных на диск и ведения журнала всех операций записи. Насколько это надежно, непонятно, не слышал чтобы кто-то использовал Redis как надежное хранилище данных.

Comments

[Александр Филиппенко]

Используют, ещё как используют)
https://habr.com/ru/post/178525/
статья 2013 года

[Илья]

Александр Филиппенко, да вижу. Пишут что в случае падения, если не повезет, потеряют до секунды данных. Если система не критична к таким потерям, то можно и так.

[Илья]

Александр Филиппенко, вот кстати есть такой видос, может будет интересно в исследовании брокеров сообщений

[Александр Филиппенко]

Илья, можно имитировать синхронную репликацию с помощью WAIT https://redis.io/topics/replication
а так же можно включить fsync AOF для каждого запроса.
Оба решения многократно просадят скорость записи, но обеспечивают персистентность на уровне релиционных СУБД.
За видос спасибо)

[Илья]

Александр Филиппенко, в этом случае все плюсы Redis как БД в оперативной памяти, пропадают) в том и дело. Он становится лишним звеном

[Александр Филиппенко]

Илья, чтение остаётся быстрым. Либо таки допускаем потерю данных за 1 секунду. В общем есть варианты и надо при выборе инструмента исходить из задачи.

[Илья]

чтение остаётся быстрым

а остается ли? вы проверяли?
кажется что с его однопоточной архитектурой все просто встанет колом и на чтение тоже