Redis发布/订阅与Rabbit MQ

Question

我的团队想转向微服务架构。当前，我们将Redis Pub / Sub用作系统中某些旧部分的消息代理。我的同事们认为，继续使用redis作为服务总线是很自然的，因为他们不想花时间研究新产品。但是在我看来，RabbitMQ（特别是与MassTransit结合使用）是微服务的更好方法。您能否将Redis Pub / Sub与Rabbit MQ进行比较，并给我一些Rabbit的参数？

Answer 1

Redis是具有可选持久性的快速内存键值存储。 Redis的发布/订阅功能是Redis产品的边际案例。

RabbitMQ是不执行其他任何操作的消息代理。它经过优化以可靠地传递消息，无论是命令样式（发送到端点交换/队列）还是发布-订阅。 RabbitMQ还包括管理插件，该管理插件提供了有用的API，可以监视代理状态，检查队列等。

在低级别的Redis客户端上使用Redis pub / sub进行交易可能会非常痛苦。您可以使用ServiceStack之类的具有更高抽象级别的库来使其更易于管理。

但是，与通过RMQ进行原始消息传递相比，MassTransit增加了很多价值。无论您决定使用哪种传输方式，只要一开始进行实际操作，就会遇到与消息传递相关的典型问题，例如处理答复，计划，长时间运行的流程，重新传递，死信队列和中毒队列。 MassTransit为您完成所有任务。 Redis或RMQ客户端都不提供任何这些。如果您的团队想花时间在自己的代码中处理这些问题，那更像是重新发明轮子。在这种情况下，使用“不愿意学习新产品”的说法听起来有些怪异，因为开发人员希望花时间解决基础结构问题，而不是为产品提供价值。

Answer 2

RabbitMQ在传递消息方面比Redis更加稳定和强大。

如果没有使用者，

RabbitMQ可以保留并存储一条消息（例如，您的听众崩溃了等等）。

RabbitMQ具有不同的通信方法：Pub / Sub，队列。可用于负载均衡等

Redis在简单情况下很方便。如果您可以承受丢失一条消息的费用并且不需要队列，那么我认为Redis也是一个不错的选择。 但是，如果您无法承受丢失一条消息的麻烦，那么Redis不是一个不错的选择。