zookeeper原理解析

zookeeper的使用场景

如果配置多个实例组成一个集群对外提供服务，那么每个实例都冗余存储了一个数据，并且独立的提供读写功能。如果需要在整个集群中保证这些数据的一致性，就需要一个leader来协调。那么问题来了：如何确认哪一个实例是leader？

问题的难点在于：
- 没有一个仲裁者来决定谁是leader
- 每个实例都冗余存储数据的情况下，无法确定哪个实例上的数据是最新的

分布式选举算法就是用来解决这个问题的。

leader选举思路概览

1. server启动时默认选举自己，并向整个集群广播
2. 收到消息时，通过3层判断：选举轮数，zxid，server id大小判断是否同意对方，如果同意，则修改自己的选票，并向集群广播
3. QuorumCnxManager负责IO处理，每2个server建立一个连接，只允许id大的server连id小的server，每个server启动单独的读写线程处理，使用阻塞IO
4. 默认超过半数机器同意时，则选举成功，修改自身状态为LEADING或FOLLOWING
5. Obserer机器不参与选举

注：
1. server id是预先配置的数据，是递增的，一个server id越新，表示越新加入集群
2. 每个服务器的逻辑时钟都是从0开始的。逻辑时钟越大，表明选举leader的进度更新（类比version字段）

zookeeper的启动过程

以一个简单的例子来说明整个选举的过程。
假设有五台服务器组成的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,所以它只能接收当小弟的命了.  
5) 服务器5启动,同4一样,当小弟

参考博文：

• 深入浅出Zookeeper之五 Leader选举，代码导读
• zookeeper3.3.3源码分析(二)FastLeader选举算法，文字描述较细
• 图解zookeeper FastLeader选举算法，整体介绍