1.总体架构
ZMQ (ZeroMQ简称ZMQ)是一个简单好用的传输层,像框架一样的一个socket library,他使得Socket编程更加简单、简洁和性能更高。是一个消息处理队列库,可在多个线程、内核和主机之间弹性伸缩。ZMQ的明确目标是“成为标准网络协议栈的一部分,之后进入Linux内核”。
ZeroMQ几乎所有的I/O操作都是异步的,主线程不会被阻塞。ZeroMQ会根据用户调用zmq_init函数时传入的接口参数,创建对应数量的I/O Thread。每个I/O Thread都有与之绑定的Poller,Poller釆用经典的Reactor模式实现,Poller根据不同操作系统平台使用不同的网络 I/O模型(select、poll、epoll、devpoll、kequeue等)。主线程与I/O线程通过Mail Box传递消息来进行通信。Server开始监听或者Client发起连接时,在主线程中创建zmq_connecter或zmq_listener,通过Mail Box发消息的形式将其绑定到I/O线程,I/O线程会把zmq_connecter或zmq_listener添加到Poller中用以侦听读/写事件。Server与Client在第一次通信时,会创建zmq_init来发送identity,用以进行认证。认证结束后,双方会为此次连接创建 Session,以后双方就通过Session进行通信。每个Session都会关联到相应的读/写管道,主线程收发消息只是分别从管 道中读/写数据。Session并不实际跟kernel交换I/O数据,而是通过plugin 到Session中的Engine来与kernel交换I/O数据。
2.所处层次
ZeroMQ 不是单独的服务或者程序,仅仅是一套组件,其封装了网络通信、消息队列、线程调度等功能,向上层提供简洁的 API,应用程序通过加载库
文件,调用API函数来实现高性能网络通信。
3.消息模型
[模型详情介绍见下文]
ZeroMQ将消息通信分成4种模型,分别是一对一结对模型(Exclusive-Pair )、 请求回应模型(Request-Reply )、发布订阅模型(Publish-Subscribe )、推拉 模型(Push-Pull )。这4种模型总结出了通用的网络通信模型,在实际中可以 根据应用需要,组合其中的2种或多种模型来形成自己的解决方案。
3.1 —对一结对模型
最简单的1:1消息通信模型,可以认为是一个TCPConnection,但是 TCP Server只能接受一个连接。数据可以双向流动,这点不同于后面的请求回应模型。
3.2请求回应模型
由请求端发起请求,然后等待回应端应答。一个请求必须对应一个回应,从请求端的角度来看是发-收配对,从回应端的角度是收-发对。跟一对一结对模型的区别在于请求端可以是1~N个。该模型主要用于远程调用及任务分配等。Echo 服务就是这种经典模型的应用。
请求回应模型
3.3发布订阅模型
发布端单向分发数据,且不关心是否把全部信息发送给订阅端。如果发布端开 始发布信息时,订阅端尚未连接上来,则这些信息会被直接丢弃。订阅端未连接 导致信息丢失的问题,可以通过与请求回应模型组合来解决。订阅端只负责接收, 而不能反馈,且在订阅端消费速度慢于发布端的情况下,会在订阅端堆积数据。
该模型主要用于数据分发。天气预报、微博明星粉丝可以应用这种经典模型。 发布订阅模型
3.4推拉模型
Server端作为Push端,而Client端作为Pull端,如果有多个Client端同 时连接到Server端,则Server端会在内部做一个负载均衡,釆用平均分配的算 法,将所有消息均衡发布到Client端上。与发布订阅模型相比,推拉模型在没 有消费者的情况下,发布的消息不会被消耗掉;在消费者能力不够的情况下,能 够提供多消费者并行消费解决方案。该模型主要用于多任务并行。
推拉模型
- zmq基本流程