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

 

背景

我正在制作发布者/订阅典型应用程序，发布者将消息发送给消费者。

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

目的

这里的目标是确保无论连接发生了什么，或者机器本身如何，发布者发送的消息总是被消费者接收。

消息的排序不是必须的。

问题

根据我的研究，RabbitMQ是此场景的正确选择：

  • Redis将RabbitMQ作为Logstash和elasticsearch之间的数据代理/消息传递系统

    • 然而，尽管RabbitMQ有关于发布和订阅者的教程，但本教程并未向我们展示持久队列，也没有提到确认我认为是确保传递消息的关键。

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

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

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

    问题

  • 对于这个用例，哪个解决方案最容易实现？ （Redis解决方案还是RabbitMQ解决方案？）
  • 请提供一个与您认为最好的例子的链接！

    • 背景

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

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

  • 这种模式并不关心消息是否被接收。 发布商只是鼓励消息，如果有任何订阅者倾听，好，否则它不在乎。

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

    分析

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

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

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

  • 工作队列
  • RPC示例

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

    rabbitMQ的倒台：

  • 这种方法的最大问题是，如果消费者/员工崩溃，则需要自己定义逻辑以确保任务不会丢失。 发生这种情况的原因是，一旦任务完成后，RPC模式和来自工作队列的持续队列一起工作，服务器将继续向工作人员发送消息，直到它再次恢复。 但是工作人员并不知道它是否已经从服务器读取了答复，所以它会从服务器收到几个ACK。 要解决这个问题，每个工作者消息需要有一个ID，保存到磁盘（如果失败）或者请求必须是幂等的。
  • 另一个问题是，如果连接丢失，客户端因错误无法连接而炸毁。 这也是你必须事先准备的。

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

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

    • 遵循官方建议。 你可以检查github回购更多的信息。

    redis的崩溃：

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

    • 在我看来，这是一个最糟糕的rabbitmq。

    结论

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

  • 更强大的官方在线文档，附带示例。
  • 消费者无需调查生产者。
  • 错误处理就像在redis中一样简单。

    • 考虑到这一点，对于这个特定情况，我有信心说在这种情况下redis是最差的。

    希望能帮助到你。

    关于实现，它们都应该很容易 - 它们都有各种语言的库，请在这里查看redis和rabbitmq。 我只是诚实的在这里：我不使用JavaScript，所以我不知道如何实施或支持受尊重的库。

    关于你在教程中没有找到的内容（或者在第二篇关于持久队列和持久消息以及确认消息的文章中没有找到），有一些很好的解释：

  • 关于持久性
  • 关于确认（与您在问题中提供的链接相同，只是为了清晰起见在此处列出）
  • 关于可靠性

    • 发布商确认不在本教程中，但在amqp.node的回购中有一个github示例。

    随着兔子mq消息传播（在大多数情况下）像这样
    publisher -> exchange -> queue -> consumer
    并且在每一个站点都有某种持久性要实现。 此外，如果您获得群集和队列镜像，您将获得更高的可靠性（当然还有可用性）。

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

    有几个名称，如disque，bull，kue，amqplib等...

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

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

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

    链接地址: http://www.djcxy.com/p/34161.html

    上一篇: Publish/Subscribe reliable messaging: Redis VS RabbitMQ

    下一篇: Memcached vs. Redis?