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

Question

背景

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

发布者和消费者在不同的机器上,它们之间的连接偶尔会中断.

目的

这里的目标是确保无论连接发生什么,或者机器本身,发布者发送的消息总是由消费者接收.

消息的排序不是必须的.

问题

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

• Redis与RabbitMQ一起作为Logstash和elasticsearch之间的数据代理/消息系统

然而,尽管拥有的RabbitMQ教程关于发布和订阅本教程不存在我们持久性的队列也未提及确认,我相信是关键,确保邮件传递.

另一方面,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有两个例子可以清楚地回答我的问题:

• 工作队列
• RPC示例

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

RabbitMQ的垮台:

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

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

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

这遵循官方建议.您可以查看github仓库了解更多信息.

redis的垮台:

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

在我看来,这是最糟糕的兔子.

结论

我最终选择了rabbitmq,理由如下:

1. 更强大的官方在线文档,附带示例.
2. 消费者无需轮询生产者.
3. 错误处理就像在redis中一样简单.

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

希望能帮助到你.