在需要並行化處理資料的時候，採用訊息佇列通訊的方式來協作，比採用共享狀態的方式要好的多。erlang ，go 都使用這一手段來讓並行任務之間協同工作。
最近讀完了 zeromq 的 guide。寫的很不錯。前幾年一直有做類似的工作，但是自己總結的不好。而 zeromq 把訊息通訊方面的模式總結的很不錯。
zeromq 把通訊的需求看成四類。其中一類是一對一結對通訊，用來支援傳統的 tcp socket 模型，但並不推薦使用。常用的通訊模式只有三類。
請求回應模型。由請求端發起請求，並等待回應端回應請求。從請求端來看，一定是一對對收發配對的；反之，在回應端一定是發收對。請求端和回應端都可以是 1:n 的模型。通常把 1 認為是 server ，n 認為是 client 。zeromq 可以很好的支援路由功能（實現路由功能的元件叫作 device），把 1:n 擴充套件為 n:m （只需要加入若干路由節點）。從這個模型看，更底層的端點位址是對上層隱藏的。每個請求都隱含有回應位址，而應用則不關心它。
發布訂閱模型。這個模型裡，發布端是單向只傳送資料的，且不關心是否把全部的資訊都傳送給訂閱端。如果發布端開始發布資訊的時候，訂閱端尚未連線上來，這些資訊直接丟棄。不過一旦訂閱端連線上來，中間會保證沒有資訊丟失。同樣，訂閱端則只負責接收，而不能反饋。如果發布端和訂閱端需要互動（比如要確認訂閱者是否已經連線上），則使用額外的 socket 採用請求回應模型滿足這個需求。
管道模型。這個模型裡，管道是單向的，從 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 放到磁碟上。
這是0mq作者用純c寫的另一套框架
應該更符和雲兄的胃口
不用zmq_msg_t和固定長度的緩衝，你怎麼接收不同長度的資料報了、怎麼合併處理業務上的分包的合併了，如果使用zeromq在公網上，會有更多的安全因素要考慮？談那麼多理論沒用，至少在請求應答模式上，對於hwclient.c／hwserver.c我試過很多方式
IM伺服器的架構
一 總的構架結構示意圖 如上圖所示，目前系統總的分成六個模組，分別為 網路 協議解析模組，使用者帳號管理模組，訊息處理模組，動作處理模組，資料均衡處理模組，客戶狀態處理模組。正常流程應該這麼實現，以乙個或者幾個執行緒執行網路 協議解析模組，然後他根據具體的包型別分發給具體的命令處理模組，每個具體的命...
IM伺服器的架構
一 總的構架結構示意圖 如上圖所示，目前系統總的分成六個模組，分別為 網路 協議解析模組，使用者帳號管理模組，訊息處理模組，動作處理模組，資料均衡處理模組，客戶狀態處理模組 正常流程應該這麼實現，以乙個或者幾個執行緒執行網路 協議解析模組，然後他根據具體的包型別分發給具體的命令處理模組，每個具體的命...
IM伺服器的架構
如上圖所示，目前系統總的分成六個模組，分別為網路 協議解析模組，使用者帳號管理模組，訊息處理模組，動作處理模組，資料均衡處理模組，客戶狀態處理模組 正常流程應該這麼實現，以乙個或者幾個執行緒執行網路 協議解析模組，然後他根據具體的包型別分發給具體的命令處理模組，每個具體的命令處理模組 至少應該分別執...