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.<clinit>(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
<dependency>
<groupId>org.zeromq</groupId>
<artifactId>jzmq</artifactId>
<version>2.2.0</version>
</dependency>即可在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状态流
参考文献
tips:本文属于自己学习和实践过程的记录，很多图和文字都粘贴自网上文章，没有注明引用请包涵！如有任何问题请留言或邮件通知，我会及时回复。
