2019獨角獸企業重金招聘Python工程師標準>>>

不知道ZeroMQ是什么，自行baidu

zmq網上宣傳很牛B，史上最快消息隊列，是不是最快我不知道，但其過度封裝，讓它在很多場合失去了可用性

下面我將一一列舉zmq自認為強大的優點

優點1：zmq將所有連接整合到一個context對象中,客戶處理成千上萬個連接時，只需要創建1個對象，不再需要維護大量的socket對象。

??? 好棒，但是請告訴我

??? 1.如何判斷消息來至于哪個連接

??? 2.如何操作某個特定的連接，比如斷開某個連接，從特定連接接收消息

?

優點2：zmq將分布式網絡總結為4大模型，比如REQ/REP模型，zmq幫你解決了業務的序列化問題，你只要選擇創建對應模型的socket就可以保證先請求的，先回應

????? 雖然業務的序列化，對程序員來說只是輕而易舉的個小事情，不過我還是要夸獎你為用戶考慮的真周到，

????? 但是請告訴我

????? 1.如何讓不同連接（業務）并發請求，因為我絕對不會在不同連接上進行序列化操作，如果業務要求兩個連接需要序列化，我一定會把它們合并成1個連接，不要給我一棵樹，卻要求我放棄一片森林啊。

?????

優點3：zmq封狀了連接重連機制，用戶不再關心網絡異常，只要對端異常恢復了，zmq就保證連接是可用的。

? ??? 但是請告訴我

????? 1.如何知道連接狀態，以適時退出無效連接上的recv等待

????? 2.pub/sub模式下，如果對端崩潰，如何知道什么時候恢復連接，以確保publish消息到達，當然我知道設置ID可以，但是發送緩沖會滿，如果對端一直不重啟，內存和硬盤會被吃光

????? 3.Req/Rep模式下，如果rep端recv后崩潰，req端如何解除send縮定

zmq諸多弊端的罪魁禍首，總結為一句話就是：將多狀態整合成了一狀態

轉載于:https://my.oschina.net/u/732357/blog/78137

總結

以上是生活随笔為你收集整理的过度封装的ZeroMQ的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。