大数据教程（3.4）：zookeeper集群角色分配原理

        1、zookeeper角色概念

        zookeeper集群中有三种角色（zookeeper服务器节点），它们分别是：群首（leader），追随者（follower），观察者（observer）。因为观察者这种节点咱们工做中基本不会接触到，故此只重点讲述前两种角色。

        群首（leader）：Leader做为整个ZooKeeper集群的主节点，负责响应全部对ZooKeeper状态变动的请求。它会将每一个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO。

        这里补充一下ZooKeeper的请求类型。对于exists，getData，getChildren等只读请求，收到该请求的zk服务器将会在本地处理，由于由其内部的ZAB理论实现，每一个服务器看到的名字空间内容都是一致的，无所谓在哪台机器上读取数据，所以若是ZooKeeper集群的负载是读多写少，而且读请求分布得均衡的话，效率是很高的。对于create，setData，delete等有写操做的请求，则须要统一转发给leader处理，leader须要决定编号、执行操做，这个过程称为一个事务（transaction）。

        追随者（follower）：Follower主要是响应本服务器上的读请求外，另外follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交。另外须要注意的是，leader和follower构成ZooKeeper集群的法定人数，也就是说，只有他们才参与新leader的选举、响应leader的提议。

        2、选举原理

（1） 第一种状况：集群是全新的集群。
        以一个简单的例子来讲明整个选举的过程. 
        假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是 同样的.假设这些服务器依序启动,来看看会发生什么：

 
        1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,因此它的选举状态一直是LOOKING状态 
        2) 服务器2启动,它与最开始启动的服务器1进行通讯,互相交换本身的选举结果,因为二者都没有历史数据,因此id值较大的服务器2胜出,可是因为没有达到超过半数以上的服务器都赞成选举它(这个例子中的半数以上是3),因此服务器1,2仍是继续保持LOOKING状态. 
        3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不一样的是,此时有三台服务器选举了它,因此它成为了此次选举的leader. 

        4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,可是因为前面已经有半数以上的服务器选举了服务器3,因此它只能成为follower了. 
        5) 服务器5启动,同4同样,成为follower.

（2）第二种状况：非全新集群的选举机制(数据恢复)
        那么，初始化的时候，是按照上述的说明进行选举的，可是当zookeeper运行了一段时间以后，有机器down掉，从新选举时，选举过程就相对复杂了。 
        须要加入数据id、leader id和逻辑时钟。 
        数据id：数据新的id就大，数据每次更新都会更新id。 
        Leader id：就是咱们配置的myid中的值，每一个机器一个。 
        逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说: 若是在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新. 

        选举的规则就变成： 
        一、逻辑时钟小的选举结果被忽略，从新投票 
        二、统一逻辑时钟后，数据id大的胜出 
        三、数据id相同的状况下，leader id大的胜出 
        根据这个规则选出leader。

     

        3、Zookeeper集群-应用程序的工做原理

 

        以上是博主今天对zookeeper角色工做原理介绍的所有内容，因为本教程的重点是大数据部分，故此处zookeeper的介绍不会详细到专家级。若是你们对zookeeper底层原理或其它知识感兴趣，请点赞并关注博主，博主将在后期推出zookeeper的详细教程。最后的最后，若是你们以为文章不错，请为博主点赞。