低延迟消息队列

Question

基本上我有一个在工作节点之间分配任务的主节点。工作人员的数量可能会改变，这意味着工作人员不能在服务器端进行硬编码。 Master 向队列提交一个任务，其中一个工作人员接受这个任务，处理它并返回结果。最关键的方面是低延迟。工作节点上的典型处理时间约为 100-300 毫秒，这意味着消息传递系统不应给处理时间增加明显的延迟。

目前我正在研究请求-响应 JMS 模式。这意味着master将任务提交到共享队列，worker将从队列中取出任务并将结果提交到另一个由master节点监听的队列。 Master 会将响应与请求关联起来。

恐怕JMS会给系统带来延迟，这是不可接受的。也许我应该看看其他解决方案？比如 RabbitMQ、JGroups 或 ZooKeeper？

如果 JMS 适合这里，你能推荐最快的 JMS 代理吗？目前我正在研究 ActiveMQ

对解决方案的另一个要求是它应该能够在云中工作

Answer 1

基于 JMS 的解决方案无法保证低延迟，因为所有供应商（无论是 Rabbit、Hornet 还是 ActiveMQ）都使用固有的消息批处理技术来实现高吞吐量。 IBM 和 Mule 等供应商已针对这项工作发布了特定的低延迟产品。

但一切都取决于您的负载和产生的任务数量以及消耗的工人数量。因此，通过调整，您可以获得您的个性化号码。

基于 LMAX 破坏者的 CoralQueue 绝对值得一看。

Answer 2

你应该看看这里 [1]，Rabbitmq 有一篇很好的性能文章和关于延迟的讨论。

快速恢复，我不得不说 Rabbitmq 在某些压力情况下可以采用 400ms 的延迟值，但通常在发送速率较低的情况下，它最接近 40ms 或更少。查看（尝试发送速率与延迟图表）

顺便说一下，您还应该考虑您的网络延迟。此基准测试显示了 localhost 性能。

[1]http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/

Answer 3

我想您正在寻找 Java 解决方案（来自 JMS）

对于高吞吐量低延迟的内存队列功能，您可以考虑 Hazelcast (http://hazelcast.org/)

它可能会...这取决于工人离开/加入集群的频率。非常频繁地添加/删除集群成员会降低效率。

另外，如果您需要持久化队列或复杂的队列管理，这也可能很麻烦。

非 java 客户端会有问题，因为您需要购买许可证。

但是，如果您只想要一个低延迟的 java 队列 - 它会解决问题

为了快速查看它是否适合您的目的，请看这里： http://docs.hazelcast.org/docs/latest/manual/html/queue.html

确保您也有良好的网络配置。如果可以的话 10gig，1gig 可以，但请确保您使用信誉良好的交换机。