Redis Pub/Sub против Rabbit MQ

Redis — это быстрое хранилище ключей и значений в памяти с дополнительным сохранением. Функция pub/sub в Redis — это маргинальный случай для Redis как продукта.

RabbitMQ — это брокер сообщений, который больше ничего не делает. Он оптимизирован для надежной доставки сообщений как в командном стиле (отправка в конечную точку обмена/в очередь), так и в режиме публикации-подписки. RabbitMQ также включает подключаемый модуль управления, который предоставляет полезный API для мониторинга состояния брокера, проверки очередей и т. д.

Работа с публикацией/подпиской Redis на низком уровне клиента Redis может быть очень болезненной. Вы можете использовать такую ​​библиотеку, как ServiceStack, которая имеет более высокий уровень абстракции, чтобы сделать ее более управляемой.

Тем не менее, MassTransit имеет большую ценность по сравнению с обменом необработанными сообщениями через RMQ. Как только вы начнете делать что-то по-настоящему, независимо от того, какой транспорт вы решите использовать, вы столкнетесь с типичными проблемами, связанными с обменом сообщениями, такими как обработка ответов, планирование, длительные процессы, повторная доставка, очереди недоставленных сообщений и т. д. ядовитые очереди. MassTransit сделает все за вас. Ни Redis, ни клиент RMQ не доставят ничего из этого. Если ваша команда хочет потратить время на решение этих проблем в своем собственном коде, это больше похоже на изобретение велосипеда. Использование аргумента «нежелание изучать новый продукт» в этом контексте звучит немного странно, поскольку вместо того, чтобы приносить пользу продукту, разработчики хотят тратить свое время на решение проблем с инфраструктурой.

RabbitMQ гораздо более стабилен и надежен, чем Redis, для передачи сообщений.

RabbitMQ может удерживать и сохранять сообщение, если для него нет потребителя (например, ваш слушатель вышел из строя и т. д.).

У RabbitMQ есть разные способы связи: Pub/Sub, Queue. Которые вы можете использовать для балансировки нагрузки и т. д.

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