我们正在构建的系统正在通过外部提要接收数据。我们的工作是将这些数据分发给多个服务,运行计算并将结果转发到其他地方-典型的发布者-订阅者情况。我们需要的是一个非常低延迟的消息传递。我们不需要像MSMQ那样持久化消息。
对于软实时消息传递,RabbitMq是否足够快?有什么基准吗?用它代替TIBCO Rendezvous是个好主意吗?还有没有其他开源的软实时消息传递替代方案?
谢谢。
发布于 2010-01-26 06:29:26
(我是rabbitmq开发人员。)
当负载较轻时,Rabbit通常会有100-400微秒的延迟,这取决于你的网卡和CPU速度。一旦负载变得更重,内部缓冲就开始出现,延迟也会增加一点。在带宽使用(每秒消息数、每秒字节数)开始变高之前,您可以放心地预期1ms的延迟。一旦引入持久性,延迟自然也会增加。
关于基准测试,这里最大的问题之一是定义什么对您的应用程序重要。Java客户机中包含了一些简单的点对点和发布订阅延迟和吞吐量测量示例;如果您对它们有问题,请在rabbitmq讨论列表中询问!它们不会测量与实际应用程序的相关性,但可能有助于减轻您对延迟或吞吐量的微基准测试的担忧。
最后,现在有很多很好的开源消息传递和与消息传递相关的系统。在AMQP的世界里,除了RabbitMQ之外,还有Qpid和OpenAMQ。如果您能够将自己限制在Java语言中(很多人已经成功地使用了ActiveMQ),那么也有很好的开源JMS服务器。针对Ruby和Python系统的轻量级系统也如雨后春笋般涌现;这些系统往往专注于单独排队,并且往往不具备AMQP提供的灵活路由功能。
发布于 2010-02-01 22:21:39
您应该能够在每个CPU上实现每秒数万条消息。例如,我们的一个标准测试每秒将25k消息从Java客户端推送到运行在四核COTS debian box上的服务器,然后返回到客户端。客户端和服务器在同一机器上运行,因此服务器上每秒处理的50k消息加上客户端上每秒处理的50k消息。您可以通过在具有更多内核的专用机箱上运行服务器来获得更高的费率。关于基于字节/秒的费率,请在rabbitmq-讨论邮件列表上询问。
亚历克西斯
发布于 2011-11-29 18:32:00
我能想到的关于您的系统的最佳解决方案是ZeroMQ。
它没有持久性,这是你说你不需要的,而且它使用起来非常快速和简单。
它不是一个AMQP实现(似乎你也不需要),但正如它在this guide上所说的那样
?MQ (ZeroMQ,0MQ,zmq)看起来像一个可嵌入的网络库,但它的行为像一个并发框架。它为您提供了通过各种传输(如进程内、进程间、TCP和多播)传输整个消息的套接字。您可以使用扇出、发布-订阅、任务分发和请求-回复等模式将套接字N-to-N连接起来。它足够快,可以作为集群产品的fabric。它的异步I/O模型为您提供了作为异步消息处理任务构建的可伸缩多核应用程序。它有大量的语言API,可以在大多数操作系统上运行。
https://stackoverflow.com/questions/2124221
复制相似问题