zeromq简介

zeroMQ不是TCP，不是socket，也不是消息队列，而是这些的综合体。

ZeroMQ以嵌入式网络编程库的形式实现了一个并行开发框架（concurrency framework），
能够提供进程内(inproc)、进程间(IPC)、网络(TCP)和广播方式的消息信道，
并支持扇出(fan-out)、发布-订阅(pub-sub)、任务分发（task distribution）、请求/响应（request-reply）等通信模式。

ZeroMQ的异步I/O模型能够为多核消息系统提供足够的扩展性。

ZeroMQ支持30多种语言的API，可以用于绝大多数操作系统。

与socket对比

ZeroMQ提供了类似于Socket的一系列接口，他跟Socket的区别是：普通的socket是端到端的（1:1的关系），而ZMQ却是可以N：M 的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等，而ZMQ屏蔽了这些细节，让你的网络编程更为简单。ZMQ用于node与node间的通信，node可以是主机或者是进程。

ZeroMQ特点

ZeroMQ是一个传输层API库，
更关注消息的传输。与消息队列相比，ZeroMQ有以下一些特点：

1 点对点无中间节点.

传统的消息队列都需要一个消息服务器来存储转发消息。而ZeroMQ则放弃了这个模式，把侧重点放在了点对点的消息传输上。

ZeroMQ能缓存消息，但是是在发送端缓存。ZeroMQ里有水位设置的相关接口来控制缓存量。当然，ZeroMQ也支持传统的消息队列（通过zmq_device来实现）。

2 强调消息收发模式

在点对点的消息传输上ZeroMQ将通信的模式做了归纳，比如常见的订阅模式（一个消息发多个客户），分发模式（N个消息平均分给X个客户）等等。下面是目前支持的消息模式配对，任何一方都可以做为服务端。

• PUB and SUB
• REQ and REP
• REQ and ROUTER (take care, REQ inserts an extra null frame)
• DEALER and REP (take care, REP assumes a null frame)
• DEALER and ROUTER
• DEALER and DEALER
• ROUTER and ROUTER
• PUSH and PULL
• PAIR and PAIR
  XPUB and XSUB是PUB and SUB的弱版本。

4种基本消息模式

ZeroMQ将消息通信分成4种模型，分别是一对一结对模型（Exclusive-Pair ）、请求回应模型（Request-Reply）、发布订阅模型（Publish-Subscribe）、推拉模型（Push-Pull）

Request-Reply请求回应模型

由请求端发起请求，然后等待回应端应答。一个请求必须对应一个回应，从请求端的角度来看是发-收配对，从回应端的角度是收-发对。跟一对一结对模型的区别在于请求端可以是1~N个。

应用场景:该模型主要用于远程调用及任务分配等。Echo服务就是这种经典模型的应用。

Publish-Subscribe发布订阅模型

发布端单向分发数据，且不关心是否把全部信息发送给订阅端。如果发布端开始发布信息时，订阅端尚未连接上来，则这些信息会被直接丢弃。订阅端未连接导致信息丢失的问题，可以通过与请求回应模型组合来解决。订阅端只负责接收，而不能反馈，且在订阅端消费速度慢于发布端的情况下，会在订阅端堆积数据。

应用场景:该模型主要用于数据分发。天气预报、微博明星粉丝可以应用这种经典模型。

注意事项：在此种模式在，SUB端在建立连接后，需要先订阅，才能接收消息，否则接收不到消息。示例如下:

ZMQ.Context context = ZMQ.context(1);
Socket subscriber = context.socket(ZMQ.SUB);
subscriber.connect("tcp://localhost:5557");
subscriber.subscribe("".getBytes());
int total = 0;
while (true) {
    byte[] bytes = subscriber.recv(0);
}

Subscribe按不同的topic主题过滤

//Publish端发送不同的topic主题
publisher.sendMore("access_point");
publisher.send(ipAddress.toByteArray(), ZMQ.NOBLOCK);
       
//topic filter过滤:根据topic过滤，不同的Subscribe订阅不同的数据    
subscriber.subscribe("access_point".getBytes());
while (true) {
    //接收topic
    byte[] bytesTopic  = subscriber.recv(0);
    // 接收数据
    byte[] bytesData = subscriber.recv(0);
}

Parallel Pipeline PUSH-PULL推拉模型 分而治之

Server端作为Push端，而Client端作为Pull端，如果有多个Client端同时连接到Server端，则Server端会在内部做一个负载均衡，采用平均分配的算法，将所有消息均衡发布到Client端上。与发布订阅模型相比，推拉模型在没有消费者的情况下，发布的消息不会被消耗掉；在消费者能力不够的情况下，能够提供多消费者并行消费解决方案。

应用场景:该模型主要用于多任务并行。

pair ：The Relay Race

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

安装

使用时，注意将防火墙端口关闭。

在CentOS下使用ZeroMQ

centos 安装 zeromq jzmq

#install zeromq
tar -xzf zeromq-2.1.7.tar.gz
cd zeromq-2.1.7
#./configure --prefix=/usr/local/zeromq  #按照此种方式，会报错，搞不定。
./configure
yum -y install libuuid-devel ##如果报错uuid-dev,安装此程序
make & make install

#install jzmq
(yum -y install libtool)
git clone https://github.com/nathanmarz/jzmq.git
cd jzmq
./autogen.sh
./configure 
make & make install

测试

/ddhome/usr/jzmq/perf
sh local_lat.sh tcp://127.0.0.1:5000 1 100
    如果报以下错误：
    Exception in thread "main" java.lang.UnsatisfiedLinkError: no jzmq in java.library.path
            at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738)
            at java.lang.Runtime.loadLibrary0(Runtime.java:823)
            at java.lang.System.loadLibrary(System.java:1028)
            at org.zeromq.ZMQ.(ZMQ.java:34)
            at local_lat.main(local_lat.java:36)
    解决方案：(不是必选项)
    vi ~/.bashrc 
    export LD_LIBRARY_PATH=/usr/local/lib

报错：错误: 找不到或无法加载主类 remote_lat。这是因为未执行./configure

sh remote_lat.sh tcp://127.0.0.1:5000 1 100

#出现下面信息，则测试成功
message size: 1 [B]　　　　　　　　　　　　#####说明测试成功
roundtrip count: 100
mean latency: 140.0 [us]

• java测试demo：
  服务器上java代码测试demo

在Windows10下使用ZeroMQ

本人只使用zeromq client接收数据，故未做编译安装，参考 ZeroMQ（Java）使用个人小心得，这里Mark一下（适用于windows64bit及32bit）,下载已编译好的文件。

已经编译好的文件，一般是三个：jzmq.dll，libzmq.dll，zmq.jar文件(这个maven中有)

两个dll文件放在jdk放置目录:%JAVA_HOME%/bin/.dll

    org.zeromq
    jzmq
    2.2.0

即可在idea中运行java代码编写的zeromq.

---

ZeroMQ进阶

iothread设置

When you create a new context, it starts with one I/O thread. The general rule of thumb is to allow one I/O thread per gigabyte of data in or out per second.

ZMQ.Context context = ZMQ.context(1); //1是iothread

Number of threads to use, usually 1 is sufficient for most use cases.
public static Context context(int ioThreads) {
        return new Context(ioThreads);
}

安全认证

zmq_plain(7)

clear-text authentication明文认证 Authentication Using SASL

The PLAIN mechanism defines a simple username/password mechanism that lets a server authenticate a client. PLAIN makes no attempt at security or confidentiality. It is intended for use on internal networks where security requirements are low. The PLAIN mechanism is defined by this document: http://rfc.zeromq.org/spec:24.内网使用，安全性低。

zmq_curve(7)

secure authentication and confidentiality安全的认证方式和保密方式

The CURVE mechanism defines a mechanism for secure authentication and confidentiality for communications between a client and a server. CURVE is intended for use on public networks. The CURVE mechanism is defined by this document: http://rfc.zeromq.org/spec:25.公网使用。

Pub-Sub Network with a Proxy 请求-应答代理

两种方式来连接多个客户端和多个服务端。

• 第一种是让客户端通过负载均衡与多个服务端进行连接。
  
• 第二种是请求-应答代理会将两个套接字分别绑定到前端和后端，供客户端和服务端套接字连接。代理装置必须要是非阻塞式的。这种方式灵活性更好。
  

The Request-Reply Mechanisms 高级请求-应答模式

联邦模式和同伴模式

The Naming Ceremony

 

 

The State Flow状态流

参考文献

• ØMQ - The Guide
• ZMQ 指南
• ZeroMQ简介
• ZeroMQ 使用（一）
• ZeroMq的研究和使用