ZeroMQ总体结构

    （翻译自Martin Sústrik的ZeroMQ一文中的Architecture Overview）

    首先我们来看一下ZeroMQ的结构图：

   

    用户使用使用套接字socket来和ZeroMQ打交道。这些套接字有点像TCP的套接字，他们之间的最主要的差别在于，ZeroMQ的单个套接字可以处理和多个套接字的通信，有点像UDP套接字的行为。

    这些socket对象存在于用户线程中。除此之外，ZeroMQ运行着许多worker线程。这些worker线程处理异步通信、从网络中读取数据、把消息放入队列、接受外来的连接请求等。

    有各种各样的对象存在于worker线程中。每一个这种对象被特定的一个父对象所拥有。相对于子对象，父对象可以存在于不同的线程中。大多数对象直接归属于socket。我们能得到一棵对象树，对于每一个socket便有这么一棵树。这棵树在关闭过程中会用到。没有哪一个对象可以关闭自己知道它关闭了它的所有子对象。这种方式确保我们能按照预期的方式关闭程序。例如，悬挂的还没传送出去的消息会在传送过程被终结时优先被传送到网络上去。

    大致地来说，存在两种异步对象：介入消息传送的对象和不介入消息传送的对象。不介入消息传送的对象必须处理连接的管理。例如，一个TCP监听对象监听外来的TCP连接请求并为每一个新的连接创建一个engine/session对象。同样的，当一个TCP连接对象试图连接到一个TCP端并成功连接后，它会创建一个engine/session对象来管理这个连接。当这个连接失败时，这个连接对象便会试着去恢复这个连接。

    而介入消息传送的对象则负责处理数据传输。这些对象由两部分组成：session对象负责和ZeroMQ 的socket对话，而engine对象负责网络上的通信。只存在着一种session对象，而对每一种ZeroMQ支持的底层通信协议都相对应存在一种engine类型。因此，我们有TCP engines, IPC engines, PGM engines等等。这个engines的集合是可以扩展的——在未来我们也许会做一些扩展，比如说，添加一个WebSocket engine 或者一个叫 SCTP 的engine。

    session对象和套接字socket交互消息。存在着两个方向传递信息并且每一个方向的传递由一个pipe对象来处理(如上图)。每一个pipe基本上是被优化过的无锁队列从而可以更快地在线程之间传递消息。

    最后，还有一个context对象，它持有全局状态，并可被所有的socket和所有的异步对象获取。