ZMQ 提供了三个基本的通信模型
- Request-Reply
- Publisher-Subscriber
- Parallel Pipeline
Request-Reply
由 Client 发起请求，并等待 Server 回应请求。请求端发送一个简单的 hello，服务端则回应一个 world。请求端和服务端都可以是 1:N 的模型。通常把 1 认为是 Server ，N 认为是 Client 。ZMQ 可以很好的支持路由功能（实现路由功能的组件叫作 Device），把 1:N 扩展为N:M （只需要加入若干路由节点）。如图 1 所示：
图1：ZMQ 的 Request-Reply 通信
需要注意的是：
a) 服务端和客户端无论谁先启动，效果是相同的，这点不同于 Socket。
b) 在服务端收到信息以前，程序是阻塞的，会一直等待客户端连接上来。
c) 服务端收到信息以后，会 send 一个“World”给客户端。值得注意的是一定是 client 连接上来以后，send 消息给 Server，然后 Server 再 rev 然后响应 client，这种一问一答式的。如果 Server 先 send，client 先 rev 是会报错的。
d) ZMQ 通信通信单元是消息，他除了知道 Bytes 的大小，他并不关心的消息格式。因此，你可以使用任何你觉得好用的数据格式。Xml、Protocol Buffers、Thrift、json 等等。
**Publish-subscribe **
我们可以想象一下天气预报的订阅模式，由一个节点提供信息源，由其他的节点，接受信息源的信息，如图 2 所示：
图2：ZMQ 的 Publish-subscribe
服务器端一直不断的广播中，如果中途有 Subscriber 端退出，并不影响他继续的广播，当 Subscriber 再连接上来的时候，收到的就是后来发送的新的信息了。这对比较晚加入的，或者是中途离开的订阅者，必然会丢失掉一部分信息，这是这个模式的一个问题，所谓的 Slow joiner。稍后，会解决这个问题。
但是，如果 Publisher 中途离开，所有的 Subscriber 会 hold 住，等待 Publisher 再上线的时候，会继续接受信息。
PipeLine 模型
想象一下这样的场景，如果需要统计各个机器的日志，我们需要将统计任务分发到各个节点机器上，最后收集统计结果，做一个汇总。PipeLine 比较适合于这种场景，他的结构图，如图 3 所示。
图3：ZMQ 的 PipeLine 模型
task ventilator 使用的是 SOCKET_PUSH，将任务分发到 Worker 节点上。而 Worker 节点上，使用 SOCKET_PULL 从上游接受任务，并使用 SOCKET_PUSH 将结果汇集到 Slink。值得注意的是，任务的分发的时候也同样有一个负载均衡的路由功能，worker 可以随时自由加入，task ventilator 可以均衡将任务分发出去。
