RabbitMQ/0MQ 桥接器

最近，我和 Michael Bridgen 实现了一个桥接器，用于将 RabbitMQ 代理与使用 0MQ 进行消息传递的应用程序连接起来。

它在这里： http://github.com/rabbitmq/rmq-0mq

那么：用户同时使用这两个产品能获得什么样的好处？

简而言之，这里涉及两个不同的视角。RabbitMQ 用户将体验到与 0MQ 用户不同的好处。那些已经同时使用两者的人将获得一种轻松互连这两种技术的方式。

这是 RabbitMQ 的博客，所以让我们从 RabbitMQ 的视角开始。

首先，也是最显而易见的，将 0MQ 用作 RabbitMQ 代理的客户端，在没有 AMQP 客户端的平台上是有意义的。想过用 Lisp 与 RabbitMQ 代理通信吗？或者，比如说，用 Cobol？这座桥梁在这里可能会派上用场。

这同样适用于操作系统/硬件平台。您需要与内存非常有限、CPU 速度非常慢或电池续航时间有限的设备通信吗？0MQ 客户端非常简洁且速度非常快，这意味着即使在慢速芯片上也能获得合理的性能。效率也转化为更低的功耗，从而使电池续航时间更长。r0mq 桥本身与 RabbitMQ 代理位于同一位置，不需要在客户端上增加额外的资源。

该桥的另一种用法则更为复杂。如果您在非常简单的场景中使用 RabbitMQ，您可能甚至不理解它。如果您正在管理一个大型地理分布的系统，它可能会成为救命稻草。该桥可用于将 RabbitMQ 代理互连成松散的联合。只需编辑两个代理的配置文件，一切都会自动运行。您不必担心代理的启动顺序、网络中断后的重新连接管理等。一个很好的特性是这些联合是真正分布式的。不需要对联合进行集中管理。只需将您的代理连接到不同公司的代理。然后，它又连接到其他公司的代理，依此类推。最终，您将拥有一个由所有参与者协作维护的松散的全球联合。

您还可以利用的另一个优势是网络资源的有效利用。与 AMQP 不同，0MQ 允许您将消息流量分割成逻辑上独立的流。您会将娱乐视频与用于维持飞机飞行的命令分开传输。这不仅意味着您永远不会遇到队头阻塞问题，而且还可以为娱乐频道和控制系统单独设置网络级别的 QoS。此外，网络工程师会很高兴能够逐流监控网络流量，而不是让“消息传递”使用大块不透明的带宽。

最后，0MQ 捆绑了 OpenPGM 库，该库实现了名为 PGM 的可靠多播协议。因此，r0mq 桥允许将消息从 RabbitMQ 代理多播到客户端（特别是 0MQ 客户端——AMQP 没有多播支持）。在将大量相同数据传递给 LAN 上的许多机器的情况下，这种功能非常有用。如果每个数据的单独副本都发送给每个订阅者，您很容易超过网络的容量。通过多播，数据只发送给所有订阅者一次，从而在订阅者数量增加时保持恒定的带宽使用量。

当您从另一面看待 r0mq 桥时，您可能正在使用 0MQ 作为网络传输进行底层开发。

使用 RabbitMQ 代理有一些明显的好处。其中最基本的是将代理用作桥梁，将 0MQ 应用程序连接到 AMQP、STOMP 或 XMPP 应用程序。

然而，真正的用例是将 RabbitMQ 作为 0MQ 网络中的“设备”使用。0MQ 附带了一些简单的预编译设备。有些硬件可以用作 0MQ 设备（例如，在多播传输情况下使用 IP 交换机）。曾有一些尝试创建更复杂的设备，但这些都处于非常早期的开发阶段。因此，0MQ 开发人员缺少一个功能齐全、复杂且生产就绪的设备。

RabbitMQ 代理可以充当这样的设备。首先，它已被广泛部署，因此足够稳定，可以安全地用于生产环境。至于功能集，它提供了比 0MQ 世界中找到的任何东西都多的功能。两个最有用的功能是持久化和监控。

持久化意味着通过代理的消息被保存在磁盘上。当您关闭代理时，如果由于停电或其他技术问题导致服务器崩溃，消息仍然可以在磁盘上找到。当代理重新启动时，它们将像崩溃从未发生过一样被进一步发送。这类似于电子邮件的工作方式。

持久化之外，对监控的需求可能更高。一旦拥有一个非简单的系统，您就想知道每个节点在做什么：对于特定的 feed 有多少条消息已存储？当前的吞吐量是多少？等等。RabbitMQ 可以通过其 命令行工具 或通过 管理插件 来告诉您这些信息。

总而言之，我想强调的是，连接 0MQ 和 RabbitMQ 不仅仅是连接两个不兼容但大致相当的产品时所获得的低级桥梁。RabbitMQ 和 0MQ 关注消息传递的不同方面。0MQ 更注重消息如何在网络上传输。另一方面，RabbitMQ 则侧重于消息如何存储、过滤和监控。通过结合这两种技术，您可以获得两全其美的优势。

尽情享受吧！