发布/订阅可靠消息：Redis VS RabbitMQ

Question

背景

我正在制作一个发布/订阅典型应用程序，其中发布者向消费者发送消息。

发布者和消费者在不同的计算机上，它们之间的连接偶尔会中断。

目的

此处的目标是确保无论连接发生什么情况或机器本身，发布商发送的消息始终 消费者 >。

消息的排序不是必须的。

问题

根据我的研究，RabbitMQ是这种情况的正确选择：

• Redis Vs RabbitMQ as a data broker/messaging system in between Logstash and elasticsearch

然而，尽管RabbitMQ有一个关于publish and subscriber的教程，但本教程并没有向我们展示持久性队列，也没有提到confirms，我认为这是确保消息传递的关键。

另一方面，Redis也能够做到这一点：

• http://abhinavsingh.com/customizing-redis-pubsub-for-message-persistence-part-2/

但我找不到任何正式的教程或示例，我当前的轻描淡写使我相信持久性队列和消息确认必须由我们完成，因为Redis主要是在内存数据存储区而不是像消息代理一样RabbitMQ的。

问题

1. 对于这个用例，哪种解决方案最容易实现？ （Redis解决方案或RabbitMQ解决方案？）
2. 请提供您认为最好的示例的链接！

Answer 1

背景

我最初想要发布和订阅消息和队列持久性。

理论上，这并不完全适合发布和订阅：

• 这种模式并不关心是否接收到消息。发布者只是粉丝消息，如果有任何订阅者倾听，那么好，否则它并不关心。

确实，考虑到我的需求，我需要更多的工作队列模式，甚至是RPC模式。

分析

人们说两者都应该很容易，但这确实是主观的。

RabbitMQ总体上有更好的官方文档，在大多数语言中有清晰的例子，而Redis信息主要在第三方博客和稀疏的github repos中 - 这使得它更难找到。

至于这些例子，RabbitMQ有两个例子可以清楚地回答我的问题：

• Work queues
• RPC example

通过混合两者，我可以让发布者向几个消费者发送可靠消息 - 即使其中一个失败了。信息不会丢失，也不会被遗忘。

RabbitMQ的垮台：

• 这种方法的最大问题是，如果消费者/工作者崩溃，您需要自己定义逻辑以确保任务不会丢失。发生这种情况是因为一旦任务完成，在使用工作队列中的持久队列的RPC模式之后，服务器将继续向工作人员发送消息，直到它再次恢复。但是工作人员不知道它是否已经从服务器读取了回复，因此它将从服务器获取几个ACK。要解决此问题，每个工作人员消息都需要有一个ID，您可以将其保存到磁盘（如果发生故障），或者请求必须是幂等的。
• 另一个问题是，如果连接丢失，客户端无法连接时会出错。这也是你必须提前做好准备的事情。

至于redis，它在这个博客中有一个很好的持久队列示例：

• https://danielkokott.wordpress.com/2015/02/14/redis-reliable-queue-pattern/

在官方recommendation之后。您可以查看github repo了解详情。

redis的垮台：

• 与rabbitmq一样，您还需要自己处理工作人员崩溃，否则正在进行的任务将丢失。
• 你必须做投票。每个消费者需要每隔X秒向生产者询问是否有任何新闻。

在我看来，这是最糟糕的兔子。

结论

由于以下原因，我最终选择了rabbitmq：

1. 更强大的官方在线文档，附带示例。
2. 消费者无需对制作人进行投票。
3. 错误处理与redis一样简单。

考虑到这一点，对于这个具体案例，我有信心说redis在这种情况下是最糟糕的兔子。

希望它有所帮助。

Answer 2

我认为它们都很容易使用，因为为它们开发了许多库。

有一些名字如disque，bull，kue，amqplib等...

他们的文件非常好。您可以简单地复制和粘贴，并在几分钟内运行。

我使用seneca和seneca amqp是一个非常好的例子

https://github.com/senecajs/seneca-amqp-transport