轉(zhuǎn)載自:http://www.kongch.com/2012/01/zeromq-pub-sub/
Publish-subscribe Pattern：發(fā)布訂閱模式。
現(xiàn)實(shí)中，并不是所有請(qǐng)求都期待答復(fù)，而不期待答復(fù)，自然就沒(méi)有了狀態(tài)。所以相對(duì)于REQ-REP，PUB-SUB模式容易理解也簡(jiǎn)單得多。廣播聽(tīng)過(guò)吧?收音機(jī)用過(guò)吧?就這個(gè)意思。
相應(yīng)地，該模式下的socket也就兩種：ZMQ_PUB & ZMQ_SUB。 分別對(duì)應(yīng)電臺(tái)和收音機(jī)。
ZMQ_PUB
ZMQ_PUB主要用來(lái)讓消息發(fā)布者用來(lái)散發(fā)消息的。所有連接上的peer都能收到由它散發(fā)的消息。 zmq_recv(3) 這個(gè)API是不能用在這個(gè)socket上的，原因顯而易見(jiàn)。而zmq_send作用在該socket上時(shí)是永遠(yuǎn)不會(huì)阻塞的，如果訂閱者異常，發(fā)出的消息則會(huì)被丟棄。
| 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
很明顯，訂閱者通過(guò)這個(gè)socket來(lái)接受發(fā)布者發(fā)布的消息。需要注意的是，在使用該socket時(shí)，必須顯式地調(diào)用zmq_setsockopt ，設(shè)置ZMQ_SUBSCRIBE和filter。如果不設(shè)置的話，是收不到任何消息的。
| 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 |
總結(jié)
PUB-SUB模式一般處理的都不是系統(tǒng)的關(guān)鍵數(shù)據(jù)。發(fā)布者不關(guān)注訂閱者是否收到發(fā)布的消息，訂閱者也不知道自己是否收到了發(fā)布者發(fā)出的所有消息。你也不知道訂閱者何時(shí)開(kāi)始收到消息。因此邏輯上，它都不是可靠的。
事實(shí)上，即便你先啟動(dòng)訂閱者，再啟動(dòng)發(fā)布者。訂閱者也不一定能收到所有的消息。原因在于：發(fā)布者已啟動(dòng)就開(kāi)始撒布消息，而這時(shí)訂閱者可能還沒(méi)有完成連接。如果一定需要保證，則需要做兩者的同步。最傻的方法就是讓發(fā)布者啟動(dòng)之后sleep一會(huì)兒再開(kāi)始發(fā)消息，不過(guò)這種方式就跟聽(tīng)起來(lái)一樣不靠譜。
一個(gè)訂閱者可以訂閱多個(gè)發(fā)布者。同時(shí)訂閱者通過(guò)filter來(lái)過(guò)濾自己需要的消息，需要注意的時(shí)，filter是在訂閱端起作用的。也就是說(shuō)所有消息是會(huì)到達(dá)所有訂閱者處，訂閱者根據(jù)filter丟掉自己不需要的消息。