轉載自:http://www.kongch.com/2012/01/zeromq-pub-sub/
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丟掉自己不需要的消息。