过分封装的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诸多弊端的罪魁祸首，总结为一句话就是：将多状态整合成了一状态