1. ZeroMQ背景知识(version-4.2.0)
ZMQ(以下ZeroMQ简称ZMQ)是一个简单好用的、轻量级的消息组件,像框架一样的一个socket library。它的本质是个消息处理队列库,在BSD socket基础上做了一层封装,将网络通讯、进程通讯和线程通讯抽象为统一的接口,可在多个线程、内核和主机盒之间弹性伸缩。
2. ZMQ的几种模型
- Client-server模型(http://rfc.zeromq.org/spec:41/CLISRV/)
- client端可以连接一个或多个server。当连接到多个server时,发送数据采用轮询的方式;接收数据采用公平队列按序接收。
- client端在没有可用连接时会阻塞,或者返回错误。(除非特殊配置)
- server端可以连接0或多个client。它只能回复client的请求信息,应答数据会送到指定的client端。接收数据采用公平队列按序接受。
- server端应答时,若client端接收队列已满,会马上返回(重试),不会阻塞。
- 任何一对client-server都是全双工的,每端都会维护两个队列用于收发数据。
- 无论哪端,都不会因为不能入队列丢弃消息。
- client和server套接字是线程安全的。
- Publish-subscribe模型(http://rfc.zeromq.org/spec:29)
- pub端向一系列sub或xsub端广播数据,并且只发数据,会丢弃所有从sub端(一般是xsub)发送过来的数据。
- pub端在sub端接收队列已满的情况下,会丢弃发送数据,不会堵塞。
- pub端会将数据发送到所有订阅消息的sub端。
- xpub拓展了pub,可以从同时收发数据。在接收数据时,会将订阅和非订阅的sub端数据提交给应用程序。
- sub端连接了任意多个pub或xpub端,只会接收数据(除向pub端发送订阅非订阅外),采用公平队列策略。
- xsub拓展了sub,可以同时收发数据。在pub端接收队列已满的情况下,会丢弃所发送的数据,不会阻塞。
- Pipline模型(http://rfc.zeromq.org/spec:30)
- push端采用轮询的方式向任意多个pull端发送数据。
- push端在没有可用连接时,发送数据会阻塞,或者返回一个错误。
- push端在无可用连接时不会接收应用程序的数据,因此不会丢弃数据。
- pull端采用公平队列的方式接收一系列push端的数据。
- push端不能接收数据,同样,pull端不能发送数据。
- Exclusive pair模型(http://rfc.zeromq.org/spec:31)
- peer两端互连,一个用于进程间通讯的模型
- 当peer进入静音模式时(缓冲区满或未建立连接),任何一方的发送数据都会被阻塞,因此不会丢弃数据。
- Native模型
- 用于TCP连接两端进行异步请求和应答的模型。
- 在将接收到的数据传递给应用程序之前,socket会提前准备一个包含数据发送端id的消息。
- 在发送消息时,会移除消息的第一部分用于路由选择,再将剩余的消息发送到指定id的接收端。不能路由的消息会返回错误信息并发送失败。
// Create a new ZMQ context
void *context = zmq_ctx_new();
// For client-server pattern
void *client_receiver = zmq_socket(context, ZMQ_CLIENT)
void *server_receiver = zmq_socket(context, ZMQ_SERVER)
// For publish-subscribe pattern
void *pub_receiver = zmq_socket(context, ZMQ_PUB)
void *xpub_receiver = zmq_socket(context, ZMQ_XPUB)
void *sub_receiver = zmq_socket(context, ZMQ_SUB)
void *xsub_receiver = zmq_socket(context, ZMQ_XSUB)
// For pipeline pattern
void *push_receiver = zmq_socket(context, ZMQ_PUSH)
void *pull_receiver = zmq_socket(context, ZMQ_PULL)
// For exclusive pair pattern
void *pair_receiver = zmq_socket(context, ZMQ_PAIR)
int rc;
rc = zmq_bind(pair_receiver, "inproc://#1")
assert(rc == 0);
rc = zmq_connect(pair_receiver, "inproc://#1")
assert(rc == 0);
// Native pattern
void *stream_receiver = zmq_socket(context, ZMQ_STREAM)
3. I/O模型
- (同步)阻塞式I/O模型
-
默认情形下,所有的socket都是阻塞的。以用户线程在内核进行IO操作为例,用户在发起read系统调用后发生阻塞,转到内核空间,内核等到数据到达后将数据拷到用户空间,完成操作,线程返回。如下图所示:
阻塞式I/O模型
-
- (同步)非阻塞式I/O模型
-
通过将socket设置为非阻塞式的,可以在IO不能立即响应时返回一个错误,此时并没有数据返回。用户线程需不断重复发起IO请求,直到数据到达后才能得到真正的数据,剩余部分和阻塞式I/O相同。如下图所示:
非阻塞式I/O模型 - 非阻塞式I/O模型一般很少直接使用,往往实在其他模型中使用非阻塞这一特性。因为该模型需要反复发起IO请求,消耗了大量的CPU资源。
-
- (同步)I/O复用模型
-
建立在内核提供的select基础之上,可以避免非阻塞式I/O模型中轮询等待的问题。与阻塞式I/O不同,I/O复用模型会阻塞在select或poll调用处,直到等待的套接字中有变为可读的。如下图所示:
I/O复用模型
-
- 异步I/O模型
-
异步I/O需要操作系统更强的支持,与I/O复用不同,异步I/O不需要用户线程自行读取数据、处理数据,而是讲这些工作讲给操作系统完成,只接收内核通知I/O事件已经完成。如下图所示:
异步I/O模型 - 异步I/O中,用户需要自行编写处理数据的回调程序并递交给操作系统。相比较于I/O复用,异步I/O并十分常用。很多高性能并发服务器使用I/O复用加多线程任务处理的架构基本可以满足需求。
-
网友评论