zookeeper浅谈

1、ZooKeeper是什么？

ZooKeeper 是一个开源的分布式服务框架Hadoop的一个子项目，Zookeeper 实现诸如数据发布/订阅、统一命名服务、分布式协调/通知、配置管理、分布式锁和分布式队列等功能，通俗的讲zookeeper是一个支持增删查改的类似文件系统特点的数据库，按照规则去给节点分配任务。zookeeper底层实现了存储文件和通知回调功能它的数据结构类似于一个标准的文件系统，相比较文件系统zk的每个节点都可以存储数据，但是大小限制为1M。通常我们在使用dubbo的时候会建议使用zookeeper作为注册中心，也可以用redis,eureka作为注册中心，当然我只用过zookeeper,dubbo相当于搭载一个服务框架，zookeeper则是服务注册的中心。

zk的数据结构

zk服务的配置文件

上面提到zk就是一个数据库那么它的数据就储存在dataDir中，上图中的配置是一个集群配置，有server1,server2,server3三台服务器，我们这里是一个伪集群(同一台机器启动三个server),我们可以看到localhost:A:B,其中licalhost是我们的服务ip,A是专门用来选举的端口，B集群进行通信端口，clientPort是对client提供服务的端口。

名词解释：

数据发布/订阅：初始化节点的时候在服务节点注册一个数据变更Watcher ，对节点进行变更操作的时候会将数据通知到客户端，客户端接受到变更通知后会重新读取变更后的数据。

统一命名服务：获得全局的唯一名称，还可以借助znode顺序节点的特性产生的节点都会返回顺序编号，在按照给定的名字，生成具有特殊含义的统一名字，所有客户端可创建同一个名字的不同顺序节点。

2、服务器的角色？以及状态

服务器有Leader、Follower、Observer三种角色 ，其中Leader是集群内部各个服务的调度者，保证了事务处理的顺序性。Follower参与Proposal的投票，参与Leader选举投票，处理客户端的非事务请求，转发事务请求(增删改，数据变更的操作)给Leader服务器。Observer不参与投票，在不参与集群事务能力的基础上提升集群的非事务处理能力。

服务器的状态分别为LOOKING(认为进群中服务器没有Leader寻找Leader的状态)、FOLLOWING(服务器角色是Follower的状态)、LEADING(服务器角色是 Leader的状)、OBSERVING(服务器角色是Observer的状态)。

领导者选举发生的节点有Leader挂掉的时候，集群服务器启动的时候，Follower挂掉后Leader发现没有过半的Follower跟随了，这三种情况会触发领导者选举。

3、zookeeper如何解决数据一致性问题？

zookeeper server的启动过程经历了什么。

若要了解zookeepr如何解决数据一致性，zookeeper其实想达到的是强一致性，但是最终达到的是最终一致性，首先我们了解下什么是CAP?这个大家自行百度，ZK遵循的是CP原则，牺牲了可用性，满足了强一致性。如下图数据库A 的数据进行了变更为2后，在步骤2进行读取的时候不能读取到的是1，那么要求数据库之间同步非常迅速或者在步骤2上加上锁待数据同步完成后再读取到结果.

强一致性的例子

我们来大致跟下源码中的选举流程我用的是git上的3.6.1的版本，找到zkServer.sh

找到守护进程的启动脚本

找到参数中ZOOMAIN="org.apache.zookeeper.server.quorum.QuorumPeerMain"对应的这个类就是你查看源码服务的入口了。

在入口main方法中有一个初始化方法，main.initializeAndRun(args);这个方法进入以后图中标红的是进入集群模式的方法，我们来看这个方法。

判断为集群模式

进入方法之后你会看到一堆set，读取配置文件值到QuorumPeer这个对象中呢，然后是对象的start,在启动的时候就进行了调用选举方法。

大家想一下zookeeper为何选择奇数服务器？

这个要从zookeeper的过半机制说起，假如6台机器只最大允许集群中宕掉2台机器，5 台机器也是允许宕机两台，从资源利用的角度所以建议选择奇数台服务器.

标红的这块为//投票决定方式，默认超过半数就通过

标红的为leader选举方法

默认electionAlgorithm为3

在FastLeaderElection类中lookForLeader方法的case looking 条件下进行投票选举。private boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch)将收到的对方的投票与当前自己的投票对比，判断对方的投票是否优于自己的投票。

totalOrderPredicate

只要当前服务器状态为LOOKING，进入循环，不断地读取其它Server发来的通知、进行比较、更新自己的投票、发送自己的投票、统计投票结果，直到leader选出或出错退出。

选举比重参数

①Serverid：服务器ID比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大。

②Zxid：事务日志id,事务请求每次就会生成一条事务日志，服务器中存放的最大数据ID.值越大说明数据越新，在选举算法中数据越新权重越大。

③Epoch：逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比

集群启动投票流程

①每个Server会发出一个投票，因此对于Server1，Server2和Server3来说，都会将自己作为Leader服务器来进行投票，每次投票包含最基本的元素有：所推举的服务器的myid和zxid，我们以(myid,zxid)的形式来表示，即Server1的投票为(1,0),Server2的投票为(2,0),然后各自将这个投票发给集群中其他所有机器。

② 接收来自各个服务器的投票，判断该投票的有效性，包括检查是否是本轮投票，是否来自LOOKING状态的服务器。

③ pk投票，在接收到来自其他服务器的投票后，针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK:

1. 优先检查zxid，zxid比较大的服务器优先作为Leader。

2. 如果zxid相同的话，那么就比较myid，myid比较大的服务器作为Leader服务器。结果Server1{(2,0),(2,0)},Server2{(2,0),2,0)}将票投给了Server2,那么Server3也就直接跟随投给了Sever2，最终确定了Leader。

作者：宜信技术学院 王巧敏