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

【问题标题】：Message queuing solution for millions of topics数百万主题的消息队列解决方案
【发布时间】：2012-08-22 06:33:59
【问题描述】：

我正在考虑一个系统，它会通知多个消费者发生在一组对象上的事件。每个订阅者都应该能够订阅发生在零个或多个对象上的事件，多个订阅者应该能够接收有关发生在单个对象上的事件的信息。

我认为某些消息队列系统在这种情况下是合适的，但我不确定如何处理我将拥有数百万个对象的事实 - 为每个对象使用单独的主题听起来不太好 [还是很好？]。

您能否建议我应该采取的方法，甚至是一些合理的开源消息队列系统？

更多细节：

将有成千上万的订阅者 [意味着数量不多]，
每个订阅者将订阅数十或数百个对象，
将有大约 5-2000 万个对象，
事件本身不必携带任何消息。只需知道该对象已更改的信息就足够了，
绝大多数对象将永远不会被订阅，
事件以每秒几百个的最大速率发生，
理想情况下服务器应该在linux下运行，能够通过http long-poll与生态系统的其他部分集成[使用node js？码头下的延续？]。

提前感谢您的反馈，对于有些含糊的问题，我们深表歉意！

【问题讨论】：

这是一个根本上难以以可扩展的方式解决的问题，正如 Twitter 一直存在的问题所证明的那样。您可以使用标准的主题订阅者模型，并使用一个技巧来限制主题的数量：例如，主题 ID 可以是消息 ID 模 1000。然后主题的侦听器将只过滤他们感兴趣的消息关于。（只是一个想法）
@Aapo Kyrola - 感谢您的提示。你能把你的评论作为答案吗？或许你可以推荐特定的消息队列服务器？
你看过aws.amazon.com/sqs吗？以及他们可以提供的所有工具（通知等）
@Resh32 - 感谢您的提示，但我正在寻找可以在内部使用的解决方案。
我最近读到了一篇关于 twitter 上的人们如何使用 Scala 的有趣文章：artima.com/scalazine/articles/twitter_on_scala.html

标签： message-queue ibm-mq mq

【解决方案1】：

由于您的消息非常小，可能需要考虑 MQTT，它是为小型设备设计的，尽管它也适用于功能强大的设备。关键考虑是低开销 - 基本上是小消息的 2 字节标头。由于您的体积，您可能无法使用任何简单或开源的 MQTT 服务器。您可能需要像 MessageSight 这样的重型专用设备来处理您的音量。

有关您的应用程序的更多详细信息肯定会有所帮助。你也根本没有提到安全性。我想你一定在这方面有一些需求。

【讨论】：

感谢您的回答。实际上，这将是“受信任”进程/机器之间的所有内部流量——因此不需要安全功能。

【解决方案2】：

虽然不确定您的工作环境，但这里是我的一些观点。您能否在系统中识别具有唯一 ID 的每个对象。如果是这样，您可以为每种事件类型设置一个主题。例如您要跟踪对象删除事件、对象更新事件等。因此，您可以为每种事件类型设置主题。每当对象发生相应的事件时，这些主题将与对象的 ID 一起发布。这将限制您需要的主题数量。您问题的第二部分是不同的订阅者想要订阅不同的对象。因此，并非所有订阅者都对了解所有对象的事件感兴趣。此问题陈述的范围为消息传递框架提供的消息选择器（过滤）机制。所以基本上你需要在什么基础上寻找对特定对象感兴趣的订阅者。具有作为消息过滤机制的基础。它可以是任何东西：对象类型、对象状态等。因此，最终您的系统将由每个事件类型的一个主题组成，其中有人发布事件消息：{object-type:object-id} 信息。订阅者可以订阅任何主题并使用过滤条件。

如果上述方案满足，您可以使用任何消息传递方案：activeMQ、WMQ、RabbitMQ。

【讨论】：

我可以通过 id 识别对象。我不需要追踪发生了什么；发生某事的信息就足够了，它会告诉客户端检索对象详细信息。订阅者将订阅 [相对] 非常少的对象。

【解决方案3】：

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

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

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

我最推荐的选项是 ActiveMQ、RabbitMQ 和 Redis PUB SUB（Havent 确实在 redis pub-sub 上工作过，请谨慎使用）

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

刚刚看到你每秒只有很少 100 条消息被推送，这对 activemq 来说没什么大不了的，我一直在每秒处理 240 条消息的系统上使用 Amq，它运行良好。我使用工作线程池来异步处理消息。如果您在 java 领域，请查看 akka 之类的框架，如果不坚持使用 nodejs 和它周围的酷生态系统。

【讨论】：

【解决方案4】：

我强烈推荐RabbitMQ。我之前在几个项目中使用过它，根据我的经验，我认为它非常可靠并且提供了广泛的配置。基本上，RabbitMQ 是一个实现Advanced Message Queuing Protocol (AMQP) 标准的open-source (Mozilla Public License (MPL)) 消息代理。

如 RabbitMQ 网站上所述：

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

...表示支持Linux等操作系统。

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

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

在我从事的项目中，我使用 C# 和两个不同的包装器EasyNetQ 和 Burrow.NET 与 RabbitMQ 进行了通信。两者都是 RabbitMQ 的优秀包装器，但我最终成为 Burrow.NET 的最粉丝，因为它更容易和更明显地使用（不会在引擎盖下做很多魔法）并且提供了很好的灵活性来注入记录器、序列化器、等等

我从来没有处理过你要处理的大量对象——我处理过数千个（而不是数百万个）对象。然而，无论我玩过多少对象，RabbitMQ 一直都非常稳定，从来没有成为系统错误的根源。

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

【讨论】：

【解决方案5】：

如果它必须是开源的，我会选择 ActiveMQ，以及为主题提供 JMS 功能的应用程序服务器，它具有 Ajax Support，因此您可以从您的客户端访问它们

因此，您将使用 JMS 基础架构来发布对象的主题，而您 can create topis as you need them

此外，通过使用 java 应用程序服务器，您可以利用集群、负载平衡和其他高可用性功能（显然基于所选产品）

希望对你有帮助！！！

【讨论】：

ActiveMQ 可以处理数百万个主题吗？
我猜是这样，但是，它不是关于主题，而是关于硬件（一些 CPU 肯定有很多 RAM）和底层操作系统n（在任何给定时间的连接数量，套接字/线程，以及 TCP 堆栈的限制）
老实说，我正在寻找具有类似尺寸经验的人的答案，而不是假设“它应该工作”。不过还是谢谢。
ActiveMQ 是一个非常可靠的消息传递实现。它可能无法每秒处理数百万条消息。但是有一些方法可以调整它以吐火。 activemq.apache.org/performance.html