低延迟消息队列

Question

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

目前，我正在考虑请求-响应JMS模式。这意味着主节点将任务提交到共享队列，工人将从队列中获取任务并将结果提交给主节点监听的另一个队列。Master会将响应与请求关联起来。

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

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

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

Answer 1

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

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

基于LMAX disruptor的CoralQueue绝对值得一看。

Answer 2

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

快速总结一下，我不得不说Rabbitmq在一些有压力的情况下可以接受400ms的延迟值，但通常在低发送速率的情况下，它最接近40ms或更少。查看(尝试发送速率与延迟的关系图)

顺便说一句，你也应该考虑到你的网络延迟。该基准测试显示了本地主机性能。

1

Answer 3

我假设您正在寻找Java解决方案(来自JMS)

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

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

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

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

但是，如果您只想要一个低延迟的java队列，那么它就可以满足您的需求。

要快速查看它是否适合您的目的，请查看此处：http://docs.hazelcast.org/docs/latest/manual/html/queue.html

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