Есть ли какие-либо компромиссы в выборе RabbitMQ над Redis как ServiceStack MQ Broker?

Question

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

Грубая схема процесса:

ServiceStack внешний веб-сервис будет получать HTTP сообщения и отправлять эти DTOs сразу к прочному очереди сообщений. Я могу представить, что эта конкретная очередь/тема PubSub, так как у меня есть ряд других процессов, которые могут быть уведомлены, один из них будет процессом хранения сообщения по историческим причинам, другой - действовать на самом сообщении и выполнять некоторые операции ... списки подписчиков/клиентов продолжаются и продолжают.

Есть ли что-нибудь, что удерживает меня от реализации чего-то в этом направлении, за исключением моего очень ограниченного опыта работы с ServiceStack и надежной опорой на основе очереди?

Мое чтение до сих пор включили эти статьи:

Redis Persistence

Redis persistence demystified

ServiceStack - Messaging and Redis

ServiceStack - SMessageService

ServiceStack - RedisMqServerTest

Спасибо, Стефану

Answer 1

Там нет никаких особенностей в Redis MQ, которые не в Rabbit MQ, одно ограничение Rabbit MQ сервер действительно есть то, что RetryCount невыполненных сообщений может быть только 0 или 1 (в Redis MQ это может быть любое число).

Первичный компромисс заключается в том, что для этого требуется кролик MQ Broker, который является дополнительной инфраструктурной зависимостью для сред, которые уже запущены Redis. Функция, Кролик MQ имеет более Redis MQ является Ack поддержка, когда сообщение удаляется только от брокера, если он явно признал на клиенте:

var responseMsg = mqClient.Get<HelloResponse>(QueueNames<HelloResponse>.In); 
mqClient.Ack(responseMsg);