Брокер сообщений: RabbitMQ или Redis

[Yuri Fedoseev]

Всем добрый день.

Встала задача использовать брокер сообщений для передачи сообщений между сервисами для background-задач. Интенсивность сообщений планируется небольшая (задачи импорта и выгрузки отчетности).

Изначально смотрел в сторону RabbitMQ, но сейчас все больше встречаю хороших отзывов об использовании Redis для pub\sub. Кто использовал Rabbit или Redis как pub\sub в продакшене, можете поделиться впечатлениями и дать совет? Спасибо.

[Alexander Byndyu]

Привет!

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

Если уже выбрал, то расскажи что и как работает? :)

Best regards,

Alexander Byndyu

CEO at ByndyuSoft

byndyusoft.com

Phone: +7 (904) 305 5263
Skype: alexander.byndyu
Blog: http://blog.byndyu.ru
Twitter: alexanderbyndyu

--

---
Вы получили это сообщение, поскольку подписаны на группу "dotnetconf".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Yuri Fedoseev]

В итоге выбрал редис: проще конфигурировать и планируется пока небольшое кол-во сообщений. Запустили пару месяцев назад, пока исходную версию не пришлось править. Для клиента взял StackExchange.Redis - удобное api.

Как работает:

Обработчик подписывается через механизм pub\sub слушать сообщения с определенным ключом. Когда клиент хочет послать таск на обработку, то dto с данными таска кладется в "очередь", реализованную через List в редисе. DTO кладется через команду listLeftPush. После этого делается publish сообщения, которое подхватывают все подписчики. Подписчик, получив сообщение, проверяет "очередь", используя listRightPop. Если вернулся не null, то запускается поток с обработкой таска. listRightPop - атомарная операция: если один из подписчиков получил таск из очереди, то остальные точно его не получат - это исключает возможность коллизии. 

Важно, что через pub\sub передаются только уведомления о том, что нужно проверить "очередь" на наличие новых тасков. Механизм pub\sub не гарантирует доставку сообщения. Используя list для очереди мы сводим к минимуму возможность потери таска (только в случае отключения самого редис).

C редис работаем через консоль с помощью redis-cli, пока этого хватает.

Было интересно это настраивать с нуля, я думаю, что по мере добавления новых задач модуль будет дорабатываться и усложняться. Ну и наступим, конечно, на какие-нибудь грабли:) Пока что несколько месяцев все работает без проблем.