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