基本上我有一个在工作节点之间分配任务的主节点。工作人员的数量可能会改变，这意味着工作人员不能在服务器端进行硬编码。Master 向队列提交一个任务，其中一个工作人员接受这个任务，处理它并返回结果。最关键的方面是低延迟。工作节点上的典型处理时间约为 100-300 毫秒，这意味着消息系统不应该对处理时间增加明显的延迟。
目前我正在研究请求-响应 JMS 模式。这意味着 master 会将任务提交到共享队列，worker 将从队列中取出任务并将结果提交到另一个由 master 节点侦听的队列。Master 会将响应与请求相关联。
恐怕JMS可能会给系统带来延迟，这是不能接受的。也许我应该看看其他解决方案？比如 RabbitMQ、JGroups 还是 ZooKeeper？
如果 JMS 适合这里，你能推荐最快的 JMS 代理吗？目前我正在看 ActiveMQ
该解决方案的另一个要求是它应该能够在云中工作
基于 JMS 的解决方案不能保证低延迟，因为所有供应商都使用固有的消息批处理技术，无论是 Rabbit、Hornet 还是 ActiveMQ，以实现高吞吐量。IBM 和 Mule 等供应商已经为这项工作发布了特定的低延迟产品。
但是一切都取决于您的负载和产生的任务数量以及消耗的工人数量。因此，通过调整，您可以获得您的个性化号码。
基于 LMAX Disruptor 的 CoralQueue 绝对值得一看。
我想您正在寻找 Java 解决方案（来自 JMS）
对于高吞吐量低延迟内存队列功能，您可以考虑 Hazelcast ( http://hazelcast.org/ )
它可能会......这取决于工人离开/加入集群的频率。非常频繁地添加/删除集群成员会降低效率。
此外，如果您需要持久化队列或复杂的队列管理，这也可能很麻烦。
非 Java 客户端会出现问题，因为您需要购买许可证。
但是，如果您只想要一个低延迟的 Java 队列 - 它会成功
为了快速查看它是否适合您的目的，请看这里：http: //docs.hazelcast.org/docs/latest/manual/html/queue.html
确保您也有良好的网络配置。如果可以的话 10gig，1gig 可以，但请确保您使用信誉良好的交换机。
你应该看看这里 [1]，Rabbitmq 有一篇很好的性能文章和关于延迟的讨论。
快速恢复，我不得不说 Rabbitmq 在某些压力情况下可以采用 400ms 的延迟值，但通常在发送速率较低的情况下，它最接近 40ms 或更少。看一下（尝试发送速率与延迟图表）
顺便说一句，您还应该考虑您的网络延迟。该基准测试显示了本地主机性能。
[1] http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/