【大话QT之九】ZMQ偏执海盗模型调研以及模拟实现网盘负载均衡间消息通讯

应用需求：

        由于网盘服务端既需要承载用户文件目录的监控又要负责文件的上传和下载，当某一时刻用户访问量较大或用户操作较为频繁是，单台文件监控服务器和文件传输服务器往往无法满足需求，极端情况下很可能造成服务器内存和CPU使用率爆表的情况，而且当Client与文件监控服务器间网络状况不好的情况下，很有可能造成用户操作序列的丢失，即用户在客户端的操作序列没有及时反映到服务端，造成用户本地目录和服务器端存储的文件不一致的情况。基于上述情况的考虑，必须要设计一套负载均衡系统，它能够满足在用户访问量增加或用户操作增加的情况下，能过通过在多台服务器之间调度，使用户的操作顺利进行。这篇文章不重点介绍负载均衡模型的架构（会在后面的文章中进行介绍），而是重点研究它的通信模型如何实现，即在分布式的情况下如何实现多节点之间可靠的消息传递。

调研方向：

        通过调研，我们决定采用ZMQ来实现我们的网络层的通信。ZeroMQ以下简称ZMQ是一个简单好用的传输层，像框架一样的一个socket library，它使得socket编程更加简单、简洁和性能更高。它是一个消息处理队列库，可在多个线程、内核和主机之间弹性伸缩。它逐渐成为一套解决分布式环境中节点之间消息通信的标准。ZMQ并不像是一个传统意义上的消息队列服务器，事实上，它也根本不是一个服务器，它更像是一个底层的网络通讯库，在Socket API之上做了一层封装，将网络通讯、进程通讯和线程通讯抽象为统一的API接口。

         ZMQ提供了三个基本的通信模型，分别是"Request-Reply"，"Publisher-Subscriber"，"Parallel Pipeline"，其它的模型都是在这三类基本模型的基础上通过组合装配衍生出来的。下面我们就来详细地分析ZMQ中使用心跳来实现可靠通信的偏执海盗模式的通信原理，注意：该文不是简单的介绍ZMQ如何使用，所以如果你还没有对ZMQ有个清晰的了解，强烈建议你先对ZMQ的三个基本模型有了大致的了解之后再结合本文分析会更有益处。

偏执海盗模型通信原理分析：

        1> 偏执海盗通信模型图

                                                   

              这里我们分三部分来简单描述下偏执海盗模式的实现：Client端、Queue服务器以及Worker工作者节点。

              首先，Client是建立的ZMQ_REQ类型的socket，它主要负责与Queue（ROUTER类型的socket）节点建立连接，并将自己的任务发送给Queue节点（本质就是需要处理的数据）。这里需要提出的一点是Client端对可靠性做出的努力，当任务发送给Queue节点后，在特定的时间内如果没有响应，则Client端则认定上次的链接已经失效，它会将原有建立的socket关闭，然后重新建立一个socket尝试与Queue节点建立通信，并重新发送数据。

              其次，Worker节点在启动后会向Queue节点建立通信连接，并发送READY的信息申请注册，Queue节点会将该Worker的标识（其实就是socket标识符）记录下来，保存在工作者队列中，等待Queue节点给它分配任务。同时，worker会定期向Queue节点发送心跳信息（它也会接收来自Queue的心跳信息），当worker长时间没有向Queue节点发送心跳信息，在Queue端就会认定该worker已经失效，会将它在工作者队列中删除掉，这样它就不会再接收到Queue节点发送给它的任务。当worker再次重新启动时