当输入通道在一个端点被打开时，ChannelListeners (通道监听者)本质上扮演输入信息的守护监听。当消息被接收时，它会被传递到一个线程池然后被 MessageHandler (消息处理者)处理。因此如上所述，消息都是根据他们接收的顺序被异步处理的。此外，这是在我学习 Go 之前，它成为 Java 的理想代替品，因为它相当适合解决这个问题。
消息是端点间的数据交换，来自我们可以建立的文档与文档间片段。文档是通过应用被结构化定义的数据，而文档片段是根据粗的或细的需求来确定粒度所表示的部分文档，或者增量。
Zinc是围绕着发布-订阅（publish-subscribe）和推送-拉取（push-pull）的消息模式建立的。一个端点将会作为集群的主机，其他主机作为客户端。使用这样的架构，主机作为发布者而客户端作为订阅者。因此，主机发布一条消息，它就会发布到每一个订阅的客户端，这类似多播的方式。相反地，客户端一直扮演着“推送（push）”端点，而主机是“拉取（pull）”端点。这些客户端可以把消息推送到主机的消息队列，主机以先进先出方式从队列中拉取。
这种结构允许消息被传送到整个集群----客户端修改使其发送给主机，主机发送增量给所有的客户端。这也就意味着引起变化的客户端将受到一个“回应”变量，但是在检查消息源的时候它将被丢弃，消息源是一个能特殊标识端点的UUID。客户端然后在必要的情况下负责数据的一致性，或许通过操作转换或保持一个客户端能综合的单一来源的事实。
这种结构的一个优点就是它的规模合理，因为它的可组合性。具体来说，我们可以建构我们的集群客户提供任意广度和深度的树。显而易见，越从水平和垂直上扩大规模，越容易带来边缘结点之间的延迟。再加上最后的一致性，这可能会造成一些应用的问题，但是或许会被接受。
缺点是这种固有的客户端--服务器模型引入了单点故障的特征。一种解决办法是当主机有问题时提升其他的结点而且平衡整个树。
再次，这个框架主要作为我的学术支持和测试驱动 ZeroMQ 的方式，虽然已经存在其他一些有趣的类似的应用。本框架支持通过推送或发布订阅机制的多播消息的传递，下面是一个自主负载均衡的用例。
匹配像 Zoomkeeper，或其他一些服务发现协议，客户机将能够发现主机，主机将作为负载平衡器。一旦客户机发现了一个主机，它可以请求成为主机的群集的一部分。如果主机接受请求，客户端可以发送消息给主机（并且，因此，建立一个集群），同样，从主机接收消息（和集群休息）。这使客户机和主机成为提交工作的集群，通过这样一个均匀分布的方式进行处理，并且可决定是否将进一步扩展这个树或使其处理这个工作。客户机可以自己决定是否参与负载均衡集群，当他们成为可用的，他们大多是有自主权。客户可以快速运作，并且向下运作使用，比如像，Docker 容器。
ZeroMQ 在实现可靠、快速和可拓展的分布式消息上是很不错的，但它在一个单一的机器或几个局部网络中，通过跨进程通信使用相同的模式所进行并行计算的同样有用。它还表明可以毫不费力地在每台机器上进行多核操作。ZeroMQ 是一个不可替代的消息代理，但它可以和传统的面向消息的中间件协调一致的工作。结合协议缓冲区和其他序列化方法，ZeroMQ 可以很容易建立非常高通量信息框架。
ZeroMQ 的详细介绍：请点这里
ZeroMQ 的下载地址：请点这里
相关阅读：
在Ubuntu 11.04上安装ZeroMQ