Request-reply, which connects a set of clients to a set of services. This is a remote procedure call and task distribution pattern.请求回应模型。由请求端发起请求，并等待回应端回应请求。从请求端来看，一定是一对对收发配对的；反之，在回应端一定是发收对。请求端和回应端都可以是 1:N 的模型。通常把 1 认为是 server ，N 认为是 Client 。ZeroMQ 可以很好的支持路由功能（实现路由功能的组件叫作 Device），把 1:N 扩展为 N:M （只需要加入若干路由节点）。从这个模型看，更底层的端点地址是对上层隐藏的。每个请求都隐含有回应地址，而应用则不关心它。

Publish-subscribe, which connects a set of publishers to a set of subscribers. This is a data distribution pattern.发布订阅模型。这个模型里，发布端是单向只发送数据的，且不关心是否把全部的信息都发送给订阅端。如果发布端开始发布信息的时候，订阅端尚未连接上来，这些信息直接丢弃。不过一旦订阅端连接上来，中间会保证没有信息丢失。同样，订阅端则只负责接收，而不能反馈。如果发布端和订阅端需要交互（比如要确认订阅者是否已经连接上），则使用额外的 socket 采用请求回应模型满足这个需求。

Pipeline, connects nodes in a fan-out / fan-in pattern that can have multiple steps, and loops. This is a parallel task distribution and collection pattern.管道模型。这个模型里，管道是单向的，从 PUSH 端单向的向 PULL 端单向的推送数据流。

Exclusive pair, which connects two sockets in an exclusive pair. This is a low-level pattern for specific, advanced use-cases. We'll see an example at the end of this chapter.配对模型？？？

任何分布式，并行的需求，都可以用这三种模型组合起来解决问题。ZeroMQ 只专注和解决了消息通讯这一基本问题，干的非常漂亮。

基于定义好的模型，我们可以看到，api 可以实现的非常简单易用。我们不再需要 bind/listen/accept 来架设服务器，因为这个模型天然是 1:N 而不是 1:1 的，不需要为每个通道保留一个句柄。我们也不必在意 server 是否先启动（bind），而后才能让 client 工作起来（connect）。

这以上模型中，关注的是通讯双方的职责，而不是实现的方式：监听端口还是连接对方端口。对于复杂的多进程协同工作的系统, 不必纠结于进程启动的次序（在我前几年设计的系统中，启动脚本写起来就非常麻烦）。

使用 ZeroMQ 不必在意底层实现是使用短连接还是长连接方式。ZeroMQ 中的 Transient (短暂) 和 Durable (持久) socket 也并非区别于实现层是否保持了 tcp 连接。而是概念上的不同。对于 Durable socket ，其生命期可以长于一个进程的生命期，即使进程退出，再次启动后依旧可以维持继续之前的 socket 。当然，这并不是帮助你挽救你的程序因出错而崩溃的。它只是提出这个模式，让你根据设计需要可以实现。对于 ZeroMQ ，如有需求（若内存有限），甚至把数据传输的 buffer 放到磁盘上。

· PUB and SUB 发布-订阅模型

· REQ and REP 请求-响应模型

· REQ and ROUTER 请求-路由模型

· DEALER and REP 

· DEALER and ROUTER

· DEALER and DEALER

· ROUTER and ROUTER 路由-路由模型

· PUSH and PULL 推-拉模型

· PAIR and PAIR 

ØMQ应用程序没有锁，可并行运行。此外，它可在多个线程、内核和主机盒之间弹性伸缩。 

· ZeroMQ交互是面向消息的。它将人们每天为应用程序周而复始地进行的例行消息处理封装起来。这意味着如果当客户端套接字发送一条150KB大小的消息时，服务端套接字无需显式处理任何缓存（buffer）或组帧，即能接接收到一条完整而相同的消息。

· ZeroMQ套接字与传输协议无关：对于任何协议，只有单一且统一的发送消息和接收消息API。缺省情况下支持进程内通讯、IPC、广播和TCP。此外，协议间切换非常简单，仅需更改连接字符串的前缀即可。

· ZeroMQ套接字能感知路由和网络拓扑。因为我们不再需要显示地管理点对点的连接状态——在上面我们已经看到，所有这些都已经由ZeroMQ库封装好——所以单个ZeroMQ套接字可以绑定两个独立的端口并监听他们的入站请求消息；也可使用一个API调用向两个独立的套接字发送数据。

缺省情况下，ZeroMQ中所有的交互都是异步的。这种异步处理模型使得ZeroMQ能够将建立连接、销毁连接、重新连接的过程封装起来，同时又能实现消息传输延迟的最小化：非阻塞的含义是，应用中一般的消息处理都是并行进行的，如消息的发送、传输以及（在发送端或接收端）排队。当然，你也可以控制ZeroMQ的排队行为，只需要设定内存范围即可，甚至你还可以为每个套接字设定交换区域。所以，如果需要的话，你完全可以模拟阻塞式API，但是异步I/O是缺省的行为。 

· TCP：ZeroMQ基于消息，消息模式，而非字节流。

· XMPP：ZeroMQ更简单、快速、更底层。Jabber可建在ØMQ之上。

· AMQP：完成相同的工作，ZeroMQ要快100倍，而且不需要代理（规范更简洁——少278页）

· IPC：ZeroMQ可以跨多个主机盒，而非单台机器。

· CORBA：ZeroMQ不会将复杂到恐怖的消息格式强加于你。

· RPC：ZeroMQ完全是异步的，你可以随时增加/删除参与者。

· RFC 1149：ZeroMQ比它快多了！

· 29west LBM：ZeroMQ是自由软件！

· IBM低延迟：ZeroMQ是自由软件！

· Tibco：仍然是自由软件！

特性：

1）ZeroMQ位于(TCP/IP协议层次结构)会话层和应用层之间。ZeroMQ 并不是一个对 socket 的封装，不能用它去实现已有的网络协议。

2）无消息服务器缓存数据。它不同于传统消息中间件通过服务器缓存转发消息的方式，而是优化点对点的消息传输。ZeroMQ能缓存消息，但是是在发送端缓存。ZeroMQ里有水位设置的相关接口来控制缓存量。当然，ZeroMQ也支持传统的消息队列（通过zmq_device来实现）。

3）强调消息收发模式。

在点对点的消息传输上ZeroMQ将通信的模式做了归纳，比如常见的订阅模式（一个消息发多个客户），分发模式（N个消息平均分给X个客户）等等。下面是目前支持的消息模式配对，任何一方都可以做为服务端。

4）透明地支持多种通信方式。这主要包括：线程间通信，进程间通信，跨主机通信。只需修改连接的url即可，例如，进程间通信使用ipc:///11111, 跨主机通信使用tcp://10.5.0.170:26666, 不需要修改代码。

5）异步传输数据。通过新增一个IO线程发送数据，该IO线程在一次链接之后，不会马上释放，复用点与点之间数据链接，可以很好地提高性能。

ZeroMQ的想法和初衷是好的，让你用串行的思路写异步的消息处理程序。并且在此基础之上提炼出了常见的消息模式，让你写起程序来更加省心。库替你完成了异步消息发送、故障恢复、甚至连磁盘的buffer都提供了。不可谓不全面。同时提供的接口非常简洁。

但是，用很少的接口封装复杂的逻辑通常的结果就是：当你的业务场景跟库的设计者设想的业务场景一样时，你回很爽。但当业务有差别，或者对细节有要求时，你会很惨。用trick能解决已经算是较好的情况了。

欺骗性质的封装。

当你zmq_connect返回成功的时候，不要高兴，这并不意味着你真的创建好链接了，因为即使你连一个根本没人监听的地址也会成功，为什么呢，因为ZeroMQ认为它提供了故障恢复自动重连的机制。后面会自动重连上的。可是如果是地址错了或者对方挂了，这辈子都不会连上了，这库就傻掉了。

再比如，你发个消息，又返回成功，也不要高兴，这并不意味着对方已经能收到了。因为消息是异步发送的，而且ZeroMQ提供了消息缓存，暂时发不出去，ZeroMQ认为后面是能发得出去的。于是消息被缓存起来。于是你想设下这个缓存，发现最低为1，也就是说至少缓存一条消息。如果这消息发不出去，你也收不回来。程序如果要停，消息就丢了。这跟ZeroMQ实现异步的方式有关。ZeroMQ是用线程的方式实现异步的。如果不缓存到IO线程，那还怎么个异步法。

过度抽象且不提供细节。

ZeroMQ建立在socket之上，隐藏了细节。但是，有时候当你需要这些细节的时候，就很纠结了。比如我收到一个消息，我想知道底层连接的信息，似乎是不大可能的，因为一个ZeroMQ套接字后面可能有很多底层的套接字（而且你不可控，也不可知）。类似的情况还有不能访问消息缓冲等等。

总之，ZeroMQ把网络通信从头到脚封装了一遍，提供了一个整体的解决方案。如果我们全盘接受这个解决方案，那么没有问题，但如果只需要一部分，并且对其他部分有要求，那么会很难受。如果应用场景稍微底层一些就会发现，本来可靠的tcp被这么一封装变得不可靠了，只能把它当作一个高级的UDP来用，弱要强调消息传输的可靠性，还需要用户做很多工作。略显无奈。

当然，一下抱怨也是基于特定场景（在一些场景下ZeroMQ还是很完美的）。说明ZeroMQ本不是为此而生。又何必强求。但是官方的态度似乎是想将它做成新一代的通用的socket，这应该还有很长的路要走。

1.点对点无中间节点。

传统的消息队列都需要一个消息服务器来存储转发消息。而ZeroMQ则放弃了这个模式，把侧重点放在了点对点的消息传输上，并且（试图）做到极致。以为消息服务器最终还是转化为服务器对其他节点的点对点消息传输上。ZeroMQ能缓存消息，但是是在发送端缓存。ZeroMQ里有水位设置的相关接口来控制缓存量。当然，ZeroMQ也支持传统的消息队列（通过zmq_device来实现）。

2.强调消息收发模式。

在点对点的消息传输上ZeroMQ将通信的模式做了归纳，比如常见的订阅模式（一个消息发多个客户），分发模式（N个消息平均分给X个客户）等等。下面是目前支持的消息模式配对，任何一方都可以做为服务端。

 PUB and SUB

 REQ and REP

 REQ and XREP

 XREQ and REP

 XREQ and XREP

 XREQ and XREQ

 XREP and XREP

 PUSH and PULL

 PAIR and PAIR

3.以统一接口支持多种底层通信方式（线程间通信，进程间通信，跨主机通信）。

如果你想把本机多进程的软件放到跨主机的环境里去执行，通常要将IPC接口用套接字重写一遍。非常麻烦。而有了ZeroMQ就方便多了，只要把通信协议从"ipc:///xxx"改为"tcp://*.*.*.*:****"就可以了，其他代码通通不需要改，如果这个是从配置文件里读的话，那么程序就完全不要动了，直接复制到其他机器上就可以了。以为ZeroMQ为我们做了很多。

4.异步，强调性能。

ZeroMQ设计之初就是为了高性能的消息发送而服务的，所以其设计追求简洁高效。它发送消息是异步模式，通过单独出一个IO线程来实现，所以消息发送调用之后不要立刻释放相关资源哦，会出错的（以为还没发送完），要把资源释放函数交给ZeroMQ让ZeroMQ发完消息自己释放。

目前ZeroMQ还不是非常成熟（本文写作时最新版是2.0.10版），设计上还有一点点小缺陷，比如不能得到客户端的IP，丢消息等。不过，开发很活跃，很有潜力。另外，ZeroMQ配合Protocol buffer使用真是绝了。