我的团队想要迁移到微服务架构。目前，我们正在使用 Redis Pub/Sub 作为系统某些遗留部分的消息代理。我的同事认为，自然而然地继续使用 redis 作为服务总线，因为他们不想把时间花在研究新产品上。但在我看来，RabbitMQ（尤其是 MassTransit）是一种更好的微服务方法。您能否将 Redis Pub/Sub 与 Rabbit MQ 进行比较，并为 Rabbit 提供一些论据？
【问题讨论】：
标签： redis rabbitmq masstransit
Redis 是一种具有可选持久性的快速内存键值存储。 Redis 的发布/订阅功能是 Redis 作为产品的边缘案例。
RabbitMQ 是什么都不做的消息代理。它针对消息的可靠传递进行了优化，无论是命令样式（发送到端点交换/队列）还是发布订阅。 RabbitMQ 还包含管理插件，它提供有用的 API 来监控代理状态、检查队列等。
在低级别的 Redis 客户端上处理 Redis pub/sub 可能是一个非常痛苦的经历。您可以使用像 ServiceStack 这样具有更高抽象级别的库来使其更易于管理。
但是，与基于 RMQ 的原始消息传递相比，MassTransit 增加了很多价值。一旦你开始真正开始做事，无论你决定使用哪种传输方式，你都会遇到与消息传递相关的典型问题，例如处理回复、调度、长时间运行的进程、重新传递、死信队列和毒药队列。 MassTransit 为您完成这一切。 Redis 或 RMQ 客户端都不会提供任何这些。如果您的团队想花时间在自己的代码中处理这些问题 - 这更像是重新发明轮子。在这种情况下使用“不愿意学习新产品”的论点听起来有点奇怪，因为开发人员不想为产品提供价值，而是希望将时间花在处理基础设施问题上。
【讨论】：
RabbitMQ 在传递消息方面比 Redis 更加稳定和健壮。
RabbitMQ 能够保存并存储一条消息，如果没有消费者（例如，您的侦听器崩溃等）。
RabbitMQ 有不同的通信方式：Pub/Sub、Queue。可用于负载平衡等
Redis 对于简单的情况很方便。如果您可以承受丢失消息并且不需要队列，那么我认为 Redis 也是一个不错的选择。 但是，如果您承受不起丢失消息的代价，那么 Redis 不是一个好的选择。
【讨论】：