ZeroMQ 使用（一）

最新推荐文章于 2024-09-25 14:11:40 发布

张哲BJUT

最新推荐文章于 2024-09-25 14:11:40 发布

阅读量8.2k

点赞数 1

分类专栏： Web Development 文章标签： ZeroMQ 消息队列分布式应用网络协议

本文链接：https://blog.csdn.net/zhangzhebjut/article/details/12884149

版权

Web Development 专栏收录该内容

21 篇文章 0 订阅

订阅专栏

一 ZeroMQ简介

我们生活在一个网络的世界里，现在的程序大部分都要用到网络连接的功能。一些底层的框架使用起来比较麻烦，难以驾驭，一些抽象上层框架使用起来虽然是比较方便，但是他们速度和灵活性往往比较差。我们需要一个不但使用方便简单，而且效率还比较高的框架。功能强大的ZeroMQ正是我们所需要的。

ZeroMQ是一个网络通讯库，其主要用来为分布式应用程序开发提供进程间通信（此处的进程既可以是同一台机器上的两个进程也可以是不同机器上的两个进程）。ZeroMQ的特点在于灵活的通信手段和丰富的连接模型，并且它可以在Linux Mac OS X,Windows等多种操作系统上工作，也支持由多种语言进行访问。

ZeroMQ提供了类似于Socket的一系列接口，他跟Socket的区别是：普通的socket是端到端的（1:1的关系），而ZMQ却是可以N：M 的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等，而ZMQ屏蔽了这些细节，让你的网络编程更为简单。ZMQ用于node与node间的通信，node可以是主机或者是进程。引用官方的说法： “ZMQ(以下ZeroMQ简称ZMQ)是一个简单好用的传输层，像框架一样的一个socket library，他使得Socket编程更加简单、简洁和性能更高。它是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩"。ZMQ的明确目标是“成为标准网络协议栈的一部分，之后进入Linux内核”。现在还未看到它们的成功，但是它无疑是极具前景的，并且是人们更加需要的“传统”BSD套接字之上的一层封装。ZMQ让编写高性能网络应用程序极为简单和有趣。

注意：ZeroMQ 并不是一个对 socket 的封装，不能用它去实现已有的网络协议。它有自己的模式，不同于更底层的点对点通讯模式。它有比 tcp 协议更高一级的协议。（当然 ZeroMQ 不一定基于 TCP 协议，它也可以用于进程间和进程内通讯）它改变了通讯都基于一对一的连接这个假设。

二通信手段

ZeroMQ提供了下列底层通信的手段，包括tcp ipc inproc multicast 等，无论使用哪种手段，都可以使用统一的API进行访问，这一点可以说是ZeroMQ的魅力。

tcp 就是TCP套接字，它使用主机名和端口号进行连接

ipc 用于在同一台计算机上进行进程间通信，使用文件路径来进行连接。

（注：实际通信中使用何种通信方式与实现有关，在UNIX系操作系统

上采用到是UNIX套接字，在Windows上也许使用到是一般套接字来通

信）

inproc 用于同一进程中的线程进行通信。使用inproc通信，可以在活用线程

的同时，避免麻烦的数据共享，不仅通信效率高，编写程序也比较容

易。

multicast 是一种采用UDP实现的多播通信。

三连接模型

ZeroMQ为分布式应用程序的构建提供了丰富多彩的连接模型。

1. REQ／REP

由请求端发起请求，并等待回应端回应请求。从请求端来看，一定是收发配对的；反之，在回应端也一定是发收对。由请求端发起请求，并等待回应端回应请求。

作为网络连接来说这种模型是非常的常见,例如 HTTP等协议就遵循REQ/REP模型，通过网络进行函数调用的RPC（Remote Procedure Call,远程过程调用）也属于这一类。

注： 1.REQ/REP是一种双向的通信方式。

2.REQ/REP 套接字发送和接受消息是需要遵循一定规律的。客户端首先发送消息,然后再接收消息,如此循环如果打乱了这个顺序(如连续发送两次)则会报错。类似地,服务端必须先进行接收,后进行发送。

3.理论上你可以连接上千万个客户端到这个服务端上,而且连接都没问题,程序仍会运作得很好。你可以尝试一下先打开客户端,再打开服务端,可以看到程序仍然会正常工作。

4.ZMQ 不会关心发送消息的内容,只要知道它所包含的字节数。如何将一个对象或复杂数据类型转换成 ZMQ 可以发送的消息,这有类似 Protocol Buffers 的序列化软件可以做到。

2. PUB／SUB

PUB-SUB 套接字组合是异步的。客户端在一个循环体中接收消息,如果在SUB 套接字上发送消息则会报错;类似地,服务端可以不断地发送消息,但不能在 PUB 套接字上接收消息。

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

　　关于 PUB-SUB 套接字,还有一点需要注意:你无法得知 SUB 是何时开始接收消息的。就算你先打开了 SUB 套接字,后打开 PUB 发送消息,这时 SUB 还是会丢失一些消息的,因为建立连接是需要一些时间的（三次握手），这种“慢连接”的症状一开始会让很多人困惑,但可以用其他的办法来避免。

注意：

1.订阅者可以连接多个发布者,轮流接收消息;

2.如果发布者没有订阅者与之相连,那它发送的消息将直接被丢弃;

3.如果你使用 TCP 协议,那当订阅者处理速度过慢时,消息会在发布者处堆积。以后我们会讨论如何使用阈值(HWM)来保护发布者。

4.在目前版本的 ZMQ 中,消息的过滤是在订阅者处进行的。也就是说,发布者会向订阅者发送所有的消息,订阅者会将未订阅的消息丢弃。

5.这是一种单项的单向通信模型。

3.PUSH／PULL

这个模型里，管道是单向的，从 PUSH 端单向的向 PULL 端单向的推送数据流。管道是单向的，且不会重复取得数据，没有worker的情况下，消息不会消耗掉。负载是否均衡取决于worker的处理能力，worker是可以横向扩展的。

注意：

1. ZeroMQ 是按需连接的，因此当连接对象尚未初始化时，客户端会进入待机状态。启动顺序自由这一点非常方便，尤其是PUB／SUB和PUSH／PULL模型的连接中，如果所有服务器和客户端只能按照一定顺序来启动，那些制约就太大了。

4. PAIR

信号模式一定是一对一的，这种模式可以代替信号量和互斥锁，用于协调线程。

四总结

ZeroMQ是一个简单的API实现进程间通信的库。和直接使用套接字相比，它在一对多多对多的实现上比较容易。

在对多CPU的运用中，横跨多台计算机的进程间通信是不可或缺的，在需要并行化处理数据的时候，采用消息队列通讯的方式来协作，比采用共享状态的方式要好的多。Erlang ，Go 都使用这一手段来让并行任务之间协同工作。因此在需要考虑可扩展性的软件开发项目中，像ZeroMQ这样的进程间通信库，今后应该会变得越来越重要。

接下来的博文中会对ZeroMQ的使用做深入的介绍。