使用ZeroMQ进行分布式消息传递

“分布式系统是您不了解计算机的故障存在的系统可能会导致您自己的计算机无法使用。”-Leslie Lamport

随着云计算的普及率和可访问性的增加，分布式系统架构已经在很大程度上取代了更多的单片结构。当然，使用面向服务的架构的含义是，您现在必须处理以前从未存在的无数困难，例如容错，可用性和水平缩放。另一个有趣的复杂层次是提供节点之间的一致性，这本身就是无尽的研究所包围的问题。像Paxos  和Raft这样的算法 试图为管理复制数据提供解决方案，而其他解决方案则提供最终的一致性。

构建可扩展的分布式系统并不是一件轻而易举的事情，但与建立类似性质的实时 系统相比，它更为困难  。分布式架构是一个众所周知的问题，事实是，大多数应用程序对延迟具有高容限性。很少的系统对实时通信有明显的 需求，但是对于开发人员来说，很少有系统  提出了一个有趣的挑战。在本文中，我将探讨使用ZeroMQ以可扩展的方式处理分布式实时消息传递的问题，同时也考虑到最终一致性的概念。

智能传输层

ZeroMQ  是用C ++编写的高性能异步消息库。它不是一个专门的消息代理，而是一个嵌入式并发框架，支持各种传输的直接和扇出端点连接。ZeroMQ通过TCP，PGM（多播），进程内和进程间通道实现了许多不同的通信模式，如请求应答，pub-sub和推挽。刺目缺乏UDP支持，更多或更少的，通过设计因为ZeroMQ被设想到提供guaranteed- ISH的递送  原子 消息。图书馆没有实际的交货保证，但确实尽了最大努力。ZeroMQ 做 什么 但是，保证您永远不会收到部分消息，并且将按顺序收到消息。这很重要，因为UDP的性能提升真的只在有损或拥塞的环境中显现出来。

消息传输模式和传输的完整列表单独使ZeroMQ成为构建分布式应用程序的有吸引力的选择，但由于其可靠性，可扩展性和高吞吐量，它尤为突出。ZeroMQ和相关技术在高频交易中很受欢迎，其中财务数据的丢包通常是不可接受的¹。2011年，  CERN  实际上进行了一项比较CORBA，Ice，Thrift，ZeroMQ和其他几种其他协议的研究，用于其粒子加速器，并将ZeroMQ评为最高。

ZeroMQ使用一些技巧，使其在吞吐量方面实质上胜过 TCP套接字，例如智能消息批处理，最小化网络堆栈遍历以及禁用Nagle的算法。默认情况下（如果可能的话），消息在订户上排队，这样就可以避免用户慢的问题。然而，如果这不足够，ZeroMQ采用一种称为“自杀式蜗牛”的模式。当用户运行缓慢并且无法跟上传入的消息时，ZeroMQ会说服用户自己杀死自己。“慢”由可配置的高水位标记决定。这里的想法是，最好是快速失败，并且可以快速解决问题，而不是潜在地允许不稳定的数据流向下游。再次考虑高频交易用例。

分布式，可扩展和快速消息架构

ZeroMQ使用作为传输层的令人信服的案例。让我们进一步深入了解如何使用它来构建在实时系统中使用的消息传递框架。ZeroMQ使用相当直观，并为各种语言提供了大量的绑定，因此我们将更多地关注体系结构和消息传递范例，而不是实际的代码。

大约一年前，当我第一次开始调查ZeroMQ时，我建立了一个框架来执行称为Zinc的实时消息传递和文档同步。在这个意义上说，“文件”是一个结构良好且可变的数据 - 思考文本文档，电子表格，画布等。虽然纯粹是学术性的，但目标是为开发人员提供一个构建丰富的协作体验的框架分布式的方式。

该框架实际上有两个实现，一个由本机ZeroMQ支持，一个由纯Java实现JeroMQ ^2支持。它真的被设计为允许使用任何传输层。

锌仅围绕几个核心概念构成：端点，ChannelListeners，MessageHandler和消息。端点表示应用程序集群中的单个节点，并提供发送和接收来自其他端点的消息的功能。它具有出站和入站通道，用于分别向对等体发送消息并接收它们。

当入站通道在端点打开时，ChannelListeners基本上作为守护进程侦听传入的消息。当收到一条消息时，它被传递给一个线程池，以便由MessageHandler处理。因此，消息按照接收的顺序进行异步处理，如前所述，ZeroMQ保证有序的消息传递。除此之外，这是在我开始学习Go之前，这将使Java成为理想的替代品，因为它非常适合问题:)

消息只是在端点之间交换的数据，我们可以使用文档和DocumentFragments进行构建。文档是由应用程序定义的结构化数据，而DocumentFragment表示部分文档或增量，可根据需要进行精细或粗调。

锌是围绕发布订阅和推挽消息传递模式构建的。一个端点将作为一个集群的主机，而另一个终端则作为客户端。使用这种架构，主机充当发布者，客户端作为订阅者。因此，当主机触发消息时，它以多播方式传送到每个订阅客户端。相反，客户端也作为“推”端点，主机是“拉”端点。然后，客户端可以将消息推送到主机的Message队列中，主机以先入先出的方式从该队列中提取。

该架构允许在整个集群中传播消息 - 客户端进行更改，该更改发送到将该增量传播到所有客户端的主机。这意味着发起更改的客户端将收到一个“回显”增量，但是会通过检查唯一标识端点的消息原始消息来排除它。然后，如果有必要， 客户可以通过运营转型或维护客户端可以调和的单一的真实来源来保护数据的一致性。

这种架构的优点之一是由于其可组合性，它可以很好地缩放。具体来说，我们可以将我们的集群构建成一个具有任意宽度和深度的客户端树。显然，我们水平或垂直扩展的越多，边缘节点之间引入的延迟越多。加上最终的一致性，这可能会导致一些应用程序的问题，但可能会被其他人接受。

这种缺点本身就是引入客户端 - 服务器模型特征的单点故障。一个解决方案可能是当主机发生故障并平衡树时，促进另一个节点。

再次，这个框架主要是学术性的，并且作为我测试驱动ZeroMQ的一种方式，尽管还有其他一些有趣的应用。由于框架通过推挽或发布订阅机制支持多播消息传递，所以一种这样的用例是自主负载平衡。

与ZooKeeper等配对或一些其他服务发现协议，客户端将能够发现作为负载平衡器的主机。一旦客户端发现主机，它可以请求成为该主机集群的一部分。如果主机接受请求，客户端可以开始向主机发送消息（并因此发送到集群的其余部分），同样从主机（以及集群的其余部分）接收消息。这使客户端和主机能够将工作提交到集群，使其以均匀分布的方式进行处理，并且工作人员可以确定是否将工作进一步放在树上或自己处理。客户可以选择以自己的意愿参与负载平衡集群，并且在可用时，使其大部分是自主的。然后，客户可以使用例如，码头容器。

ZeroMQ对于实现可靠，快速和可扩展的分布式消息传递非常有用，但同样有用的是通过使用相同模式促进内部和内部通信，在单个机器或多个本地网络上执行并行计算。它也可以在每个机器上轻松利用多个核心的意义上缩小。ZeroMQ 不是消息代理的替代品，而是可以与传统的面向消息的中间件协同工作。结合协议缓冲区  和其他序列化方法，ZeroMQ可以轻松构建极高吞吐量的消息传递框架。