Redis Pub/Sub vs Rabbit MQ

Question

我的团队希望迁移到微服务架构。目前，我们正在使用Redis Pub/Sub作为我们系统的一些遗留部分的消息代理。我的同事认为，继续使用redis作为服务总线是很自然的，因为他们不想把时间花在研究新产品上。但在我看来，对于微服务，RabbitMQ (尤其是使用MassTransit)是一种更好的方法。您能否将Redis Pub/Sub与Rabbit MQ进行比较，并为Rabbit提供一些论据？

Answer 1

Redis是一个快速的内存键值存储，具有可选的持久性。Redis的发布/订阅功能对于作为产品的Redis来说是一个边缘案例。

RabbitMQ是不执行任何其他操作的消息代理。它针对可靠的消息传递进行了优化，包括命令样式(发送到端点交换/队列)和发布-订阅。RabbitMQ还包括管理插件，它提供了一个有用的应用程序接口来监控代理状态、检查队列等。

在低级别的Redis客户端上处理Redis pub/sub可能是一种非常痛苦的经历。您可以使用像ServiceStack这样的具有更高级别抽象的库来使其更易于管理。

然而，与基于RMQ的原始消息传递相比，MassTransit增加了很多价值。一旦您真正开始做事情，无论您决定使用哪种传输方式，您都会遇到与消息传递相关的典型问题，如处理回复、调度、长时间运行的流程、重新交付、死信队列和有毒队列。MassTransit为您完成了所有这些工作。Redis和RMQ客户端都不会提供这些功能。如果您的团队想花时间在自己的代码中处理这些问题-这更像是重新发明轮子。在这种情况下使用“不愿意学习新产品”的论点听起来有点奇怪，因为开发人员希望将时间花在处理基础设施问题上，而不是为产品提供价值。

Answer 2

在传递消息方面，RabbitMQ比Redis稳定和健壮得多。

如果消息没有消费者(例如，你的监听器崩溃了，等等)，RabbitMQ能够保存和存储消息()。

RabbitMQ有不同的通信方式:发布/订阅、队列。可以用来进行负载均衡等

Redis对于简单的情况很方便。如果您能够承受丢失消息的代价，并且不需要队列，那么我认为Redis也是一个很好的选择。但是，如果你不能承受丢失消息的代价，那么Redis不是一个好的选择。