（轉）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丟掉本身不須要的消息。