RabbitMQ/0MQ 桥

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

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

那么：用户通过同时使用这两款产品可以获得哪些好处呢？

简而言之，这里涉及两种不同的观点。RabbitMQ 用户将体验与 0MQ 用户不同的好处。那些已经同时使用这两款产品的用户将获得一种简单的方法来互连这两种技术。

这是 RabbitMQ 博客，所以让我们从以 Rabbit 为中心的观点开始。

首先也是最明显的是，在没有 AMQP 客户端的平台上，将 0MQ 用作 RabbitMQ 代理的客户端是有意义的。你有没有想过从 Lisp 或 -- 比如说 -- 从 Cobol 与 RabbitMQ 代理进行通信？在这种情况下，桥接可能会派上用场。

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

桥接的另一种使用方法要复杂得多。如果你在非常简单的场景中使用 RabbitMQ，你可能不会欣赏它。如果你正在管理一个大型地理分布式系统，它可能会成为你的救星。桥接可以用于将 RabbitMQ 代理互连到松散的联盟中。只需编辑两个代理的配置文件，一切都将正常工作。你无需担心代理启动的顺序，在网络中断后管理重新连接等等。一个不错的功能是，这些联盟是真正分布式的。无需对联盟进行集中管理。只需将你的代理连接到另一家公司的代理。该代理又连接到其他公司的代理，等等。最终，你将得到一个由所有参与者以协作方式维护的松散的全球联盟。

你还可以利用的另一个优势是高效地使用网络资源。与 AMQP 不同，0MQ 允许你将消息传递流量拆分为逻辑上独立的流。你可以将娱乐视频传递在一个与用于保持飞机飞行的命令分开的流中。这不仅意味着你永远不会遇到首位阻塞问题，而且还意味着可以分别为娱乐频道和转向系统设置网络级 QoS。此外，网络工程师将感谢你可以按流监控网络流量，而不是让一个大的不透明的带宽块被“消息传递”使用。

最后，0MQ 与 OpenPGM 库捆绑在一起，该库实现了一种称为 PGM 的可靠组播协议。因此，r0mq 桥接允许将消息从 RabbitMQ 代理组播到客户端（准确地说，是 0MQ 客户端 -- AMQP 不支持组播）。这种功能在大量相同数据被传递到局域网上的许多框的场景中非常有用。如果每个数据的单独副本都被发送到每个订阅者，你很容易超过网络的容量。使用组播，数据只发送一次到所有订阅者，从而保持带宽使用量恒定，即使订阅者数量增加也是如此。

当你从另一边观察 r0mq 桥接时，你可能正在使用 0MQ 作为你的网络传输进行低级开发。

使用 RabbitMQ 代理有一些明显的作用。其中最琐碎的用途是使用代理作为连接 0MQ 应用程序与 AMQP、STOMP 或 XMPP 应用程序的桥梁。

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

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

持久性意味着通过代理传递的消息将保存在磁盘上。当你关闭代理时，如果机器由于断电或其他技术问题而崩溃，消息仍然可以在磁盘上找到。当代理重新启动时，它们将被进一步发送，就像崩溃没有发生一样。这类似于电子邮件的工作方式。

与持久性一样，监控的需求可能更多。一旦你拥有了一个非平凡的系统，你就想知道每个节点在做什么：特定供稿存储了多少消息？当前吞吐量是多少？等等。RabbitMQ 可以通过其 命令行工具 或 管理插件 告诉你这些信息。

总之，我想强调，桥接 0MQ 和 RabbitMQ 不仅仅是桥接两种不兼容但或多或少等效的产品所获得的那种愚蠢的桥接。0MQ 更注重消息如何通过网络传输。另一方面，RabbitMQ 专注于消息如何存储、过滤和监控。通过结合这两种技术，你可以获得两者的优势。

尽情享受吧！