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丢掉自己不需要的消息。