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