我的团队希望转向微服务架构。目前，我们使用Redis Pub/Sub作为我们系统的一些遗留部分的消息代理。我的同事们认为继续使用redis作为服务总线是很自然的，因为他们不想把时间花在研究新产品上。但在我看来，RabbitMQ（尤其是MassTransit）是一种更好的微服务方法。你能比较一下Redis Pub/Sub和Rabbit MQ，给予我一些Rabbit的参数吗？
8zzbczxx1#
Redis是一个快速的内存键值存储，具有可选的持久性。Redis的pub/sub功能是Redis作为产品的一个边缘案例。RabbitMQ是一个消息代理，它不做任何其他事情。它针对消息的可靠传递进行了优化，包括命令样式（发送到端点交换/队列）和发布-订阅。RabbitMQ还包括管理插件，它提供了一个有用的API来监视代理状态，检查队列等。在低级别的Redis客户端上处理Redis pub/sub可能是一种非常痛苦的经历。您可以使用像ServiceStack这样的库，它具有更高级别的抽象，使其更易于管理。但是，与RMQ上的原始消息传递相比，MassTransit增加了很多价值。一旦你开始真实的做一些事情，无论你决定使用什么传输，你都会遇到与消息相关的典型问题，比如处理回复、调度、长时间运行的进程、重新交付、死信队列和有毒队列。大众运输为您做这一切。Redis或RMQ客户端都不会提供任何这些。如果你的团队想花时间在他们自己的代码中处理这些问题--这更像是重新发明轮子。在这种情况下使用“不愿意学习新产品”的论点听起来有点奇怪，因为开发人员不想为产品提供价值，而是想把时间花在处理基础设施问题上。
yruzcnhs2#
RabbitMQ在传递消息方面比Redis更加稳定和健壮。RabbitMQ能够保存和存储消息，如果消息没有消费者（例如。例如，您的监听器崩溃等）。RabbitMQ有不同的通信方法：发布/订阅、队列。可以用于负载平衡等Redis对于简单的情况很方便。如果你能承受丢失消息的代价，并且你不需要队列，那么我认为Redis也是一个不错的选择。但是，如果你不能承担丢失消息的风险，那么Redis不是一个好的选择。
q43xntqr3#
我想这取决于需要。我主要使用rabbitmq，但我有一个任务。..我有一个用户列表，通过套接字连接，并听取所有的数据。它由一个带有无限循环的脚本管理。我想在启动时连接到所有这些。我想在插入新项目时建立一个新的连接，如果项目已删除，则断开连接。如果脚本失败，我想通过重新连接所有用户来重新启动它所以……如果我只使用rabbitmq，我必须单独存储用户列表
3条答案
按热度按时间8zzbczxx1#
Redis是一个快速的内存键值存储，具有可选的持久性。Redis的pub/sub功能是Redis作为产品的一个边缘案例。
RabbitMQ是一个消息代理，它不做任何其他事情。它针对消息的可靠传递进行了优化，包括命令样式（发送到端点交换/队列）和发布-订阅。RabbitMQ还包括管理插件，它提供了一个有用的API来监视代理状态，检查队列等。
在低级别的Redis客户端上处理Redis pub/sub可能是一种非常痛苦的经历。您可以使用像ServiceStack这样的库，它具有更高级别的抽象，使其更易于管理。
但是，与RMQ上的原始消息传递相比，MassTransit增加了很多价值。一旦你开始真实的做一些事情，无论你决定使用什么传输，你都会遇到与消息相关的典型问题，比如处理回复、调度、长时间运行的进程、重新交付、死信队列和有毒队列。大众运输为您做这一切。Redis或RMQ客户端都不会提供任何这些。如果你的团队想花时间在他们自己的代码中处理这些问题--这更像是重新发明轮子。在这种情况下使用“不愿意学习新产品”的论点听起来有点奇怪，因为开发人员不想为产品提供价值，而是想把时间花在处理基础设施问题上。
yruzcnhs2#
RabbitMQ在传递消息方面比Redis更加稳定和健壮。
RabbitMQ能够保存和存储消息，如果消息没有消费者（例如。例如，您的监听器崩溃等）。
RabbitMQ有不同的通信方法：发布/订阅、队列。可以用于负载平衡等
Redis对于简单的情况很方便。如果你能承受丢失消息的代价，并且你不需要队列，那么我认为Redis也是一个不错的选择。但是，如果你不能承担丢失消息的风险，那么Redis不是一个好的选择。
q43xntqr3#
我想这取决于需要。我主要使用rabbitmq，但我有一个任务。..
我有一个用户列表，通过套接字连接，并听取所有的数据。它由一个带有无限循环的脚本管理。我想在启动时连接到所有这些。我想在插入新项目时建立一个新的连接，如果项目已删除，则断开连接。
如果脚本失败，我想通过重新连接所有用户来重新启动它
所以……如果我只使用rabbitmq，我必须单独存储用户列表