【Zookeeper】——服务端集群

         本篇博客主要是对Zookeeper服务端的集群进行简单的了解学习。

 

集群角色

        

 

Leader：Zookeeper集群中的核心，主要有两个工作：

         1、处理事务请求，保证集群事务处理的顺序性

         2、集群内部各服务器的调度者

Follower：是Zookeeper集群状态的跟随者，主要负责三项工作

         1、处理客户端的非事务请求，转发事务请求给Leader

         2、参与事务请求Proposal（建议、提议）的投票

         3、参与leader选举投票

Observer：3.3.0以后引入的新角色，它是充当的观察者，观察zk集群的最新状态变化，并将这些状态变更同步到自己。它和follower基本一致，处理客户端的非事务请求，转发事务请求给Leader。不同点是：observer不参与任何形式的投票，包括事务请求的Proposal投票和Leader选举投票。

 

引进observer的原因：分担一部分的访问提高服务端性能，同时由于observer不参与任何形式的投票添加observer不会增加投票时间。

 

扫盲

  ZAB协议

         ZookeeperAtomic Broadcast，Zookeeper原子消息广播协议。它比较重要选举的过程依赖这个协议。

         三个阶段——

                  发现：leader选举过程

                  同步：leader选出之后，follower和Observer从leader上同步最新数据

                  广播：同步完成后就可以接受客户端事务请求

        

         两种模式——

         崩溃恢复：服务框架启动过程中，或当leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式，并选举产生新的leader服务器。当选举产生了新的leader服务器，同时集群中已经有过半的机器与该leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。

 

         消息广播：leader把需要发送给follower的事务提议已广播的形式发出去，follower接受到后进行写入操作，如果成功反馈给Leader，超过一半的follower有反馈，leader则广播一个消息通知所有的follower进行commit，就是提交事务，follower接收到后就完成事务提交。Leader自己也提交

 

myid和ZXID

         myid：在安装Zookeeper中需要创建和配置的一个文件，在Zookeeper集群中的节点需要获取myid文件内容来标识该节点，myid文件的路径为一般为zoo.cfg中配置的dataDir的路径，在对应的路径下创建一个名为myid的文件然后写入内容，内容是zoo.cfg中定义的server.A这个A的值。

 

         server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 通信和数据同步端口；D 投票端口。

 

         Zk在启动的时候回读取这个文件，拿到里面的数据然后跟zoo.cfg里配置的信息比较，然后确定到底是哪个server，就是做标识用的。

 

 

         ZXID：Zookeeper状态的每一次改变, 都对应着一个递增的id, 该id称为zxid。由于zxid的递增性质，如果zxid1小于zxid2， 那么zxid1肯定先于zxid2发生。创建任意节点，或者更新任意节点的数据，或者删除任意节点，都会导致Zookeeper状态发生改变，从而导致zxid的值增加。

 

Leader选举

         服务器启动时期：

                  1、每个server会发出一个投票，形式(SID，ZXID)。[SID和myid一致]

                  2、  接受类中各个服务器的投票

                  3、  处理投票

                  4、  统计投票

                  5、  改变服务器状态

 

         Leader选举的前提条件：集群规模至少2台机器，我们以3台为例进行讲解。

 

         1、  每个Server都会发出一个投票，因为是启动这种初始情况server都会将自己作为Leader进行投票，每次投票包含最基本的元素：myid和ZXID，表现的形式是（myid，ZXID）。启动服务是一个一个启动，首先启server1，自己无法选举，然后启动server2，server2启动后两台服务器能通信，每台机器都试图找一个Leader，这就进入到Leader选举流程初始化阶段他们都会投自己server1的投票为（1,0），server2的投票为（2,0）

 

         2、  每个服务器都会接收来自其他服务器的投票，服务器接收到投票后首先判断投票的有效性，如检测是否为本轮投票，是否来自状态为Looking的服务器

 

         3、  处理投票，接收到投票后服务器需要将别人的投票和自己的投票进行PK，规则是这样的：优先检测ZXID，ZXID大的服务器优先作为Leader，如果ZXID相同，就比较myid，myid的服务作为leader。对server1和server2来说，server1的投票是（1,0）接收到的是（2,0）zxid相同，myidserver2的大所以它就会更新自己的投票为（2,0）然后重新将投票发出。Server2则不需要更新自己的投票信息，只需要再次向集群的机器上发出一次投票。

 

         4、  统计：第二次次投票后服务器开始统计得到的投票，如果收到超过半数的相同投票，这个相同投票对应的SID集群就是leader，对应server1和server2都统计出已经有两台机器接受了（2,0）投票，这就是过半，即大于或等于（n/2+1）

 

         5、  确定leader后每个服务器都会更新自己的状态，如果是follower就变为Following，如果是leader就变为leading

 

         服务运行时期：

         运行过程中只有leader挂了无法对外提供服务，才会进入新一轮的Leader选举，这个过程和服务启动时是一致的，只是在leader挂了之后其他的非Observer服务器会将自己的服务器变更为Looking，然后才开始选举。