ZeroMQ 的模式

在須要並行化處理數據的時候，採用消息隊列通信的方式來協做，比採用共享狀態的方式要好的多。Erlang ，Go 都使用這一手段來讓並行任務之間協同工做。

最近讀完了 ZeroMQ 的 Guide。寫的很不錯。前幾年一直有作相似的工做，可是本身總結的很差。而 ZeroMQ 把消息通信方面的模式總結的很不錯。

ZeroMQ 並非一個對 socket 的封裝，不能用它去實現已有的網絡協議。它有本身的模式，不一樣於更底層的點對點通信模式。它有比 tcp 協議更高一級的協議。（固然 ZeroMQ 不必定基於 TCP 協議，它也能夠用於進程間和進程內通信。）它改變了通信都基於一對一的鏈接這個假設。

ZeroMQ 把通信的需求當作四類。其中一類是一對一結對通信，用來支持傳統的 TCP socket 模型，但並不推薦使用。經常使用的通信模式只有三類。

1. 請求迴應模型。由請求端發起請求，並等待迴應端迴應請求。從請求端來看，必定是一對對收發配對的；反之，在迴應端必定是發收對。請求端和迴應端均可以是 1:N 的模型。一般把 1 認爲是 server ，N 認爲是 Client 。ZeroMQ 能夠很好的支持路由功能（實現路由功能的組件叫做 Device），把 1:N 擴展爲 N:M （只須要加入若干路由節點）。從這個模型看，更底層的端點地址是對上層隱藏的。每一個請求都隱含有迴應地址，而應用則不關心它。

2. 發佈訂閱模型。這個模型裏，發佈端是單向只發送數據的，且不關心是否把所有的信息都發送給訂閱端。若是發佈端開始發佈信息的時候，訂閱端還沒有鏈接上來，這些信息直接丟棄。不過一旦訂閱端鏈接上來，中間會保證沒有信息丟失。一樣，訂閱端則只負責接收，而不能反饋。若是發佈端和訂閱端須要交互（好比要確認訂閱者是否已經鏈接上），則使用額外的 socket 採用請求迴應模型知足這個需求。

3. 管道模型。這個模型裏，管道是單向的，從 PUSH 端單向的向 PULL 端單向的推送數據流。

任何分佈式，並行的需求，均可以用這三種模型組合起來解決問題。ZeroMQ 只專一和解決了消息通信這一基本問題，乾的很是漂亮。

基於定義好的模型，咱們能夠看到，api 能夠實現的很是簡單易用。咱們再也不須要 bind/listen/accept 來架設服務器，由於這個模型自然是 1:N 而不是 1:1 的，不須要爲每一個通道保留一個句柄。咱們也沒必要在乎 server 是否先啓動（bind），然後才能讓 client 工做起來（connect）。

這以上模型中，關注的是通信雙方的職責，而不是實現的方式：監聽端口仍是鏈接對方端口。對於複雜的多進程協同工做的系統, 沒必要糾結於進程啓動的次序（在我前幾年設計的系統中，啓動腳本寫起來就很是麻煩）。

使用 ZeroMQ 沒必要在乎底層實現是使用短鏈接仍是長鏈接方式。ZeroMQ 中的 Transient (短暫) 和 Durable (持久) socket 也並不是區別於實現層是否保持了 tcp 鏈接。而是概念上的不一樣。對於 Durable socket ，其生命期能夠長於一個進程的生命期，即便進程退出，再次啓動後依舊能夠維持繼續以前的 socket 。固然，這並非幫助你挽救你的程序因出錯而崩潰的。它只是提出這個模式，讓你根據設計須要能夠實現。對於 ZeroMQ ，若有需求（若內存有限），甚至把數據傳輸的 buffer 放到磁盤上。