数百万主题的消息队列解决方案

Question

我正在考虑系统将通知多个消费者有关一群物体发生的事件.每个订阅者应该能够订阅发生在零个或多个对象上的事件,多个订阅者应该能够接收有关发生在单个对象上的事件的信息.

我认为在这种情况下,某些消息排队系统是合适的,但我不知道如何处理我将拥有数百万个对象的事实 - 对每个对象使用单独的主题听起来不太好[或者是它正好？].

你能否建议我应该采取的方法,甚至可能是一些合理的开源消息排队系统？

更多细节:

• 会有成千上万的订阅者[意思不是很多]
• 订阅者将订阅每个数十或数百个对象,
• 将有约5-20万个物体,
• 事件本身不必携带任何信息.只是该对象被更改的信息就足够了,
• 绝大多数对象永远不会订阅,
• 事件以每秒几百个的最大速率发生,
• 理想情况下,服务器应该在linux下运行,能够通过http long-poll与生态系统的其余部分集成[使用节点js？码头下的延续？].

在此先感谢您的反馈,并抱歉有些模糊的问题!

Answer 1

我强烈推荐RabbitMQ.我之前和之后的几个项目都使用过它,我认为它非常可靠并且提供了广泛的配置.基本上,RabbitMQ是一个开源(Mozilla Public License(MPL))消息代理,它实现了高级消息队列协议(AMQP)标准.

正如RabbitMQ网站上所记录的那样:

RabbitMQ可以在Erlang支持的任何平台上运行,从嵌入式系统到多核集群和基于云的服务器.

...意味着支持像Linux这样的操作系统.

这里有一个node.js库:https://github.com/squaremo/rabbit.js

它带有一个基于HTTP的API,用于管理和监控Rab​​bitMQ服务器 - 包括命令行工具和基于浏览器的用户界面 - 请参阅:http://www.rabbitmq.com/management.html.

在我一直在使用的项目中,我使用C#和两个不同的包装器EasyNetQ和Burrow.NET与RabbitMQ进行了沟通.两者都是RabbitMQ的优秀包装器,但我最终成为Burrow.NET的粉丝,因为它更容易和更明显地工作(没有很多魔法)并且提供了良好的灵活性来注入记录器,序列化器,等等

我从未使用过您将要使用的对象数量 - 我与数千人(而不是数百万人)合作过.然而,无论我使用了多少个对象,RabbitMQ一直非常稳定,并且从未成为系统中错误的根源.

总结一下 - RabbitMQ易于使用和设置,支持AMQP,可以通过HTTP管理,我最喜欢的 - 它坚如磐石.

Answer 2

分解主题以承载特定事件，例如“对象更新主题”“对象删除”...因此客户端只需订阅他们感兴趣的基于事件的主题的“有限数量：”。

当您发布消息时，将标头注入到消息中，并将智能引入客户端以使用这些标头作为消息选择器。例如，客户端知道他感兴趣的对象列表 - 并假设您通过“id”来标识该对象 - id 可以是标头，并且客户端将使用“id header”来确定他是否感兴趣消息。

根据您是否需要，您可能还需要考虑确保有保证的传递，以确保即使消息离线并稍后返回，客户端也能收到消息。

我最推荐的选项是 ActiveMQ、RabbitMQ 和 Redis PUB SUB（还没有真正研究过 redis pub-sub，请尽职尽责）

最后是RabbitMQ和Redis的一些性能基准

刚刚看到每秒只有很少的 100 条消息被推送，这对于 activemq 来说并不是什么大问题，我一直在每秒处理 240 条消息的系统上使用 Amq，而且它工作得很好。不过，我使用工作线程池来异步处理消息。如果您在 java 领域，请看看像 akka 这样的框架，如果不坚持使用 Nodejs 及其周围很酷的生态系统。