過分封裝的ZeroMQ

不知道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諸多弊端的罪魁禍首，總結爲一句話就是：將多狀態整合成了一狀態