ZeroMQ的三种模式：请求响应、订阅发布、推送拉取

一、请求响应模式

       客户端（请求端）向服务端（响应端）发送请求，然后等待服务端应答；服务端处理收到的请求之后返回一个响应。一个请求必须对应一个响应，从请求端的角度来看是“发-收”配对，从响应端的角度是“收-发”配对。请求端可以是1~N个，如图1.1所示。

       请求响应模型主要用于请求-应答交互场景、RPC远程调用及任务分配等场景。例如：Web服务中的用户登录，用户在客户端网页（请求端）发送输入的用户名和密码，服务端（响应端）接收用户名和密码，验证是否正确。如果正确，则返回用户的登录状态及相关信息；如果错误，则返回错误信息。

图 1.1 请求响应模式

二、发布订阅模式 

        发布者发布消息到主题，订阅者接收消息，即单向分发数据。发布者不关心是否把全部信息发送给订阅端，如果发布者开始发布消息，订阅者尚未连接，则这些消息会被直接丢弃；订阅者可以根据消息主题来订阅接收其感兴趣的部分，不需要接收所有消息，也无需进行反馈，如图1.2所示。

       发布订阅模式可以应用到广播数据场景，一个发布者向多个订阅者（接收者）广播消息，其中，订阅者可以选择自己所需要主题的数据。例如：发布者（股票交易平台）负责将实时的股票数据广播出去，它不会关心哪些订阅者接收到哪些数据，只是不断发布。订阅者（投资者）可以根据自己感兴趣的股票选择订阅，假设订阅者只关心比亚迪公司的股票信息，即使发布者广播了多个股票的数据，它也只会接收到与比亚迪公司相关的数据消息。

图 1.2 发布订阅模式

​​​​​​​三、推送拉取模式

        推送者发送数据，拉取者接收数据；与发布订阅模型相比，推拉模型在没有数据接收者的情况下，发布的消息不会被消耗掉，如图1.3所示。

        推送拉取模型主要用于多任务并行处理，多个工作接点拉取任务进行并行计算；也可用于生产者-消费者模型，推送者作为任务生产者，拉取者作为任务消费者。例如：推送者（任务调度系统）负责将待处理的任务推送到处理队列，拉取者（工作节点）从任务队列中拉取需要处理的任务并行执行，拉取任务的速度取决于工作节点的处理能力。

图 1.3 推送拉取模式