选择 RabbitMQ 而不是 Redis 作为 ServiceStack MQ 代理是否有任何权衡？答案

【问题标题】：Are there any trade offs of picking RabbitMQ over Redis as a ServiceStack MQ Broker?选择 RabbitMQ 而不是 Redis 作为 ServiceStack MQ 代理是否有任何权衡？
【发布时间】：2014-10-03 05:08:36
【问题描述】：

我正处于设计基于队列的系统的初期，我希望了解将其中一个或另一个用作消息的后备存储的利弊。

流程大致流程：

ServiceStack 外部 Web 服务将接收 HTTP 消息并将这些 DTO 立即发送到持久消息队列。我可以设想这个特定的队列/主题是 PubSub，因为我有许多其他可能需要通知的进程，一个是出于历史原因存储消息的进程，另一个是对消息本身采取行动并执行一些操作...订阅者/客户列表不断增加。

除了我在 ServiceStack 和基于持久队列的消息传递方面的经验非常有限之外，是否有什么阻碍了我按照这些思路实现某些东西？

到目前为止，我的阅读包括以下文章：

Redis Persistence

Redis persistence demystified

ServiceStack - Messaging and Redis

ServiceStack - SMessageService

ServiceStack - RedisMqServerTest

谢谢你，斯蒂芬

【问题讨论】：

标签： servicestack servicestack.redis

【解决方案1】：

Redis MQ 中没有任何功能不在Rabbit MQ 中，Rabbit MQ 服务器确实存在的一个限制是失败消息的RetryCount 只能是0 或1（在Redis MQ 可以是任意数量）。

主要的权衡是它需要一个 Rabbit MQ 代理，这是已经运行 Redis 的环境的额外基础架构依赖项。 Rabbit MQ 相对于 Redis MQ 的一个特性是Ack支持，其中只有在客户端明确确认消息时才会从代理中删除消息：

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

【讨论】：