message-queue - 数百万个主题的消息排队解决方案

Question

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

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

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

更多细节:

将会有成千上万的订阅者[意味着人数不多]，

订户将每个订阅数十或数百个对象

将有大约5-20百万个对象

事件本身不必携带任何消息。只是该对象已更改的信息就足够了，

绝大多数对象将永远不会被订阅，

事件以每秒几百个的最大速率发生，

理想情况下，服务器应在linux下运行，并能够通过http long-poll [使用node js与生态系统的其余部分集成。继续跳船？]。

在此先感谢您的反馈，对于有些含糊的问题也深表歉意!

Answer 1

分解主题以举办特定事件，例如“对象更新的主题”“对象已删除” ...因此，客户端只需要订阅他们感兴趣的基于事件的主题的“有限编号:”。

当您发布消息时，将消息头插入消息中，并将信息放入客户端，以将这些消息头用作消息选择器。例如，客户知道他感兴趣的对象列表-并说您用“id”标识对象-id可以是 header ，而客户将使用“id header ”来确定他是否感兴趣消息。

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

我会推荐的最主要的选项是ActiveMQ，RabbitMQ和Redis PUB SUB(Havent确实在redis pub-sub上工作过，请尽职调查)

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

刚刚看到您每秒只有100条消息被推出，这对于activemq来说不是什么大不了的事，我一直在每秒处理240条消息的系统上使用Amq，并且工作正常。我使用工作线程池来异步处理消息。如果您在Java领域，请看一下像akka这样的框架，如果不坚持使用nodejs及其周围的凉爽的Eco系统。