（转）ZeroMQ的模式-Publish-Subscribe

Publish-subscribe Pattern：发布订阅模式。

现实中，并非全部请求都期待答复，而不期待答复，天然就没有了状态。因此相对于REQ-REP，PUB-SUB模式容易理解也简单得多。广播听过吧?收音机用过吧?就这个意思。

相应地，该模式下的socket也就两种：ZMQ_PUB & ZMQ_SUB。 分别对应电台和收音机。

ZMQ_PUB

ZMQ_PUB主要用来让消息发布者用来散发消息的。全部链接上的peer都能收到由它散发的消息。 zmq_recv(3) 这个API是不能用在这个socket上的，缘由显而易见。而zmq_send做用在该socket上时是永远不会阻塞的，若是订阅者异常，发出的消息则会被丢弃。

Summary of ZMQ_PUB characteristics
Compatible peer sockets	ZMQ_SUB
Direction	Unidirectional
Send/receive pattern	Send only
Incoming routing strategy	N/A
Outgoing routing strategy	Fan out
ZMQ_HWM option action	Drop

ZMQ_SUB

很明显，订阅者经过这个socket来接受发布者发布的消息。须要注意的是，在使用该socket时，必须显式地调用zmq_setsockopt ，设置ZMQ_SUBSCRIBE和filter。若是不设置的话，是收不到任何消息的。

Summary of ZMQ_SUB characteristics
Compatible peer sockets	ZMQ_PUB
Direction	Unidirectional
Send/receive pattern	Receive only
Incoming routing strategy	Fair-queued
Outgoing routing strategy	N/A
ZMQ_HWM option action	Drop

总结

PUB-SUB模式通常处理的都不是系统的关键数据。发布者不关注订阅者是否收到发布的消息，订阅者也不知道本身是否收到了发布者发出的全部消息。你也不知道订阅者什么时候开始收到消息。所以逻辑上，它都不是可靠的。

事实上，即使你先启动订阅者，再启动发布者。订阅者也不必定能收到全部的消息。缘由在于：发布者已启动就开始撒布消息，而这时订阅者可能尚未完成 链接。若是必定须要保证，则须要作二者的同步。最傻的方法就是让发布者启动以后sleep一下子再开始发消息，不过这种方式就跟听起来同样不靠谱。

一个订阅者能够订阅多个发布者。同时订阅者经过filter来过滤本身须要的消息，须要注意的时，filter是在订阅端起做用的。也就是说全部消息是会到达全部订阅者处，订阅者根据filter丢掉本身不须要的消息。