轉載自:http://www.kongch.com/2012/01/zeromq-pattern-requset-reply/
我們先來看看第一種模式:Request-Reply Pattern。 請求應答模式。
Request-Reply這個名字很直白，口語點說就是一問一答。可以使同步的遵循請求序的一問一答，也可以是異步的不按請求序的一問一答；其中也可以包含各種不同的路由策略——讓誰來回答。zeromq定義的為這個模式服務的socket有：ZMQ_REQ, ZMQ_REP, ZMQ_ROUTER以及ZMQ_DEALER. 用他們進行合理的組合，就可以實現現實世界中各種不同的請求應答模式。
分別來看：
ZMQ_REQ
ZMQ_REQ做的事情就是發(fā)問，然后收答。發(fā)、收必須是嚴格按序進行。請求時對對端進行Round Robin，遇到異常則阻塞。官方對這個socket的總結如下：
| Summary of ZMQ_REQ characteristics |
| Compatible peer sockets |
ZMQ_REP |
| Direction |
Bidirectional |
| Send/receive pattern |
Send, Receive, Send, Receive, … |
| Outgoing routing strategy |
Round-robin |
| Incoming routing strategy |
Last peer |
| ZMQ_HWM option action |
Block |
ZMQ_REP
ZMQ_REP做的事情是收問題然后回答。收、發(fā)嚴格按序調用。對收到的問題公平排隊,逐一作答。回答發(fā)出時遇到異常則直接丟棄，不會阻塞。
| Summary of ZMQ_REP characteristics |
| Compatible peer sockets |
ZMQ_REQ |
| Direction |
Bidirectional |
| Send/receive pattern |
Receive, Send, Receive, Send, … |
| Incoming routing strategy |
Fair-queued |
| Outgoing routing strategy |
Last peer |
| ZMQ_HWM option action |
Drop |
可以發(fā)現，上述兩種socket是純同步的，連用在它們身上的api的調用順序都有嚴格定義。而且沒有辦法動態(tài)決定請求的去向。如果要實現更復雜的請求應答模式，就要借助于下面兩種socket了。
ZMQ_DEALER
其實ZMQ_DEALER也是同步的，ZMQ_DEALER也叫作ZMQ_XREQ，概念上是request/reply socket的擴展(實現上剛好相反哦)。從名字上可知它是一個代理層。它對收到的消息公平排隊，并以RR方式發(fā)送消息，在遇到異常時發(fā)送阻塞。它的主要作用是將come in的請求load balance地發(fā)送給到對端們。
| Summary of ZMQ_DEALER characteristics |
| Compatible peer sockets |
ZMQ_ROUTER, ZMQ_REQ, ZMQ_REP |
| Direction |
Bidirectional |
| Send/receive pattern |
Unrestricted |
| Outgoing routing strategy |
Round-robin |
| Incoming routing strategy |
Fair-queued |
| ZMQ_HWM option action |
Block |
ZMQ_ROUTER
ZMQ_ROUTER是真正的異步。ZMQ_ROUTER socket收到消息時會在消息棧上加一層包含消息來源地址的消息；發(fā)送消息時，會將這一層消息取出，將其作為發(fā)送的目的地。如果發(fā)送時遇到異常，則丟棄消息。ZMQ_ROUTER通過這種方式做到了不需要保存任何狀態(tài)便可異步地轉發(fā)消息，而這一切應用層是看不到的。
| Summary of ZMQ_ROUTER characteristics |
| Compatible peer sockets |
ZMQ_DEALER, ZMQ_REQ, ZMQ_REP |
| Direction |
Bidirectional |
| Send/receive pattern |
Unrestricted |
| Outgoing routing strategy |
See text |
| Incoming routing strategy |
Fair-queued |
| ZMQ_HWM option action |
Drop |
總結
歸納總結一下，0mq的Request-Reply模式下有四種socket類型：
- DEALER： 給連接的對端RR地分發(fā)消息，對收到的消息公平排隊。
- REQ：在應用層外發(fā)的消息上加一層空消息再發(fā)送；在收到消息后去掉分隔空消息再返回應用層。它實質上是在DEALER上構建的，只是在此基礎上強制加入了發(fā)、收循環(huán)。
- ROUTER：針對每一個收到的消息：加一層來源地址段，然后再交給應用層；針對每一個要發(fā)出的消息：去掉最上層的地址段，并以該地址段為目的地進行發(fā)送。
- REP：對收到的消息：儲存所有的消息內容直到第一個分隔空消息段，把剩余的消息體傳給應用層；對發(fā)出的消息：把之前儲存的消息體加回來，并像ROUTER一樣發(fā)送出去。它實質上實在ROUTER上構建的，只是在此基礎上強制加入了收、發(fā)循環(huán)。
有了這幾種socket，便可以組合成各種Request-Reply模式了：
[REQ] <--> [REP]
[REQ] <--> [ROUTER--DEALER] <--> [REP]
[REQ] <--> [ROUTER--DEALER] <--> [ROUTER--DEALER] <--> [REP]
...
舉個例子，N個client要給M個worker提交任務，worker完成任務后返回給client；worker需要平衡負載以避免某一worker過于勞累，client發(fā)出的請求也有先后之說，不能讓后發(fā)的請求先于之前的被交給worker。這番描述的socket組合便可如下圖(from the guide)方式構建：
