RabbitMQ 高速瞬态消息传递性能
我们正在构建的系统通过外部源接收数据。我们的工作是将这些数据分发到多个服务，运行计算并将结果转发到其他地方 - 典型的发布者-订阅者情况。我们需要的是非常低延迟的消息传递。我们不需要像MSMQ那样持久化消息。
RabbitMq 对于软实时消息传递来说足够快吗？有什么基准吗？ 使用它代替 TIBCO Rendezvous 是个好主意吗？ 还有其他开源软实时消息传递替代方案吗？
谢谢。
The system we are building is receiving data through the external feed. Our job is to distribute this data to multiple services, run the calculations and forward the results elsewhere - typical publisher-subscriber situation. What we need is a very low latency messaging. We don't need to persist the messages like MSMQ.
Is RabbitMq fast enough for a soft realtime message delivery? Are there any benchmarks?
Is it a good idea to use it instead of TIBCO Rendezvous?
Are there any other open-source soft real time messaging alternatives?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
（我是一名rabbitmq开发人员。）
当负载较轻时，Rabbit通常会有100-400微秒左右的延迟，具体取决于您的网卡和CPU速度等因素。一旦负载变重，内部缓冲就会开始出现，延迟也会稍微增加。您可以安全地预期 1 毫秒的延迟，直到带宽使用（每秒消息数、每秒字节数）开始变高。当然，一旦引入持久性，延迟也会增加。
关于基准测试，这里最大的问题之一是定义对您的应用程序重要的内容。 Java 客户端包含一些非常简单的点对点和发布-订阅延迟和吞吐量测量示例；如果您对它们有疑问，请在rabbitmq讨论列表中询问！它们与实际应用程序的相关性不大，但可能有助于减轻您对延迟或吞吐量微基准的任何担忧。
最后，现在有很多很多优秀的开源消息传递和消息传递相关系统可用。单单在AMQP的世界里，除了RabbitMQ之外，还有Qpid和OpenAMQ。如果您能够将自己限制在 Java 上（许多人在 ActiveMQ 上取得了成功），那么还有一些不错的开源 JMS 服务器。许多针对 Ruby 和 Python 系统的轻量级系统也如雨后春笋般涌现；这些系统往往只专注于排队，并且往往不具备 AMQP 提供的灵活路由功能。
(I am a rabbitmq developer.)
Rabbit will, when lightly loaded, generally have latencies on the order of 100-400 microseconds, depending on things like your network card and CPU speed. Once the loading gets a little heavier, internal buffering starts to appear and latencies rise a little. You can safely expect 1ms latencies until the bandwidth use (messages-per-second, bytes-per-second) starts to get high. Latencies will also rise once persistence is introduced, naturally.
Regarding benchmarks, one of the biggest problems here is defining what's important to your application. There are some trivially simple point-to-point and pub-sub latency-and-throughput measuring examples included with the Java client; ask on the rabbitmq-discuss list if you have problems with them! They don't measure much of relevance to real-world applications, but might help allay any concerns you have regarding microbenchmarks of latency or throughput.
Finally, there are many, many good open-source messaging and messaging-related systems available these days. In the world of AMQP alone, besides RabbitMQ, there are also Qpid and OpenAMQ. There are also good open-source JMS servers out there, if you are able to restrict yourself to Java (many people have success with ActiveMQ). Lots of light-weight systems are springing up for Ruby and Python systems, as well; these systems tend to concentrate on queueing alone, and tend not to have the flexible routing capability that AMQP offers.
您应该能够实现每个 CPU 每秒处理数万条消息。例如，我们的一项标准测试每秒将 25k 消息从 Java 客户端推送到在四核 COTS debian 机器上运行的服务器，然后返回客户端。客户端和服务器在同一个机器上运行，因此服务器每秒处理 50k 消息，客户端每秒处理 50k 消息。您可以通过在具有更多内核的专用机器上运行服务器来获得更高的速率。对于基于字节/秒的速率，请在rabbitmq-discuss邮件列表上询问。
亚历克西斯
You should be able to achieve many tens of thousands of messages per second per CPU. For example one of our standard tests pushes 25k messages per second from a Java client to the server running on a quad core COTS debian box, and back to the client. The client and server are running on the same box, so that's 50k messages processed per second on the server plus 50k messages processed per second on the client. You can get higher rates by running the server on a dedicated box with more cores. For rates based on bytes/second please ask on the rabbitmq-discuss mailing list.
alexis
我能想到的关于您的系统的最佳解决方案是 ZeroMQ。
它没有持久性，你说你不需要，而且使用起来非常快速和简单。
它不是 AMQP 实现（看来您也不需要），但正如本指南：
The best solution I can think about your system is ZeroMQ.
It doesn't have persistance, that you said you don't need and it's VERY quick and simple to use.
It's not an AMQP implementation (that it seems you don't need too) but as it says on this guide: