ZeroMQ，也可以叫做zmq，0mq或者ØMQ，是时下流行的一种轻量级消息队列方式。相较于kafka等需要中间件的消息队列而言而言，zmq更快，更轻，你只需要几十行甚至更少的代码就能实现消息类型的切换。常用的ZMQ模式有Request-Reply, Pub-Sub,Push-Pull等。如果你的需要快速的实现一个简单系统，那么相信zmq是一个不错的选择。另外，zmq支持Java、Python、C++等多种语言，对于架构未来的可扩展性也有很大的弹性。
下面是zmq基本类型的描述，示例代码可以从zguide获取。重点描述这些模式的缺点，因为相信大多数同学都可以一眼看出模式的有点，但单单只会用模式还是不够的。一位国内顶尖的CPU专家曾告诉楼主，"技术人员要永远对技术本身怀着一颗敬畏的心"，runnable的程序很容易写出来，但是否稳健又是另外一回事，希望楼主能够帮助新使用zmq的同学们跳过这些“坑”。楼主主要使用python和C++，因此引用的代码也是C++代码，各位可以根据自己使用的语言找示例代码。
Reuest-Reply
如图所见，requst-reply的交互方式很简单，客户端发送请求后，服务端予以回应。详细代码可参考hwserver.cpp和hwclient.cpp
坑：
- R-R模式最大的问题是如果一旦request-reply的节奏被破坏掉，后续的交互将会不能进行。如何解决这个问题呢？Zmq提供了很多种解决方法，其中Lazy的楼主觉得Lazy Pirate模式比较简答^^, 简答来说就是client超时后加一个重试逻辑，在server比较可靠的前提下，这是一个不错的选择；
- Request端是阻塞模式，在Server busy的时候，并不会立刻返回。对于问题，楼主觉得asyncsrv.cpp里的异步模型不错,或者用Dealer-Dealer，94有点麻烦，当然有熟悉zmq的同学觉得其他模式也可以解决此问题。毕竟没有一种模式是完美的；
Pub-Sub
这种模式的可用于大规模的数据分发，同时sub端也可以订阅多个pub，示例代码为wuclient.cpp和wuserver.cpp。
坑：
- 如果在pub时，sub端口没有连接上pub，将会错误消息。处理这类问题的方法有很多，但多是都无法彻底解决，除非你有所有消息都存下来==!
- 如果sub太慢，推送队列将会堆积，最后溢出；
- 没有sub连接时，推送的消息将会被丢弃；
- zmq4.2版本的一个bug：如果sub端不停重连pub端，同时pub端没有数据推送出来，最后pub端会存在内存泄漏的风险；
- 通过外网IP跨机房使用pub-sub模式，在长时间无消息推送的时候，容易出现pub连接为establish，sub连接已经关闭的情况，初步怀疑是sub端发送的FIN+RST报文被丢弃所致（SO_LINGER=0），可能市值SO_LINGER可以解决这个问题，这个方法楼主并没有尝试过，有兴趣的同学可以试试；
PUSH-PULL
和pub-sub不同，pub-sub是一种“all of many”的模式，push-pull是"one of many"。上图中，PUSH可以为1个端口，PULL为多个端口。
坑：
如果没有PULL或者由于PULL处理太慢，导致通道阻塞（跟PUSH端的HWM设置相关，HWM的具体含义可以百度一下，楼主也会在后续博客中），那么PUSH端发送数据时将会阻塞；
先写到这里，有空再更新……
参考文献：
http://zguide.zeromq.org/