分布式系列教程（14） -分布式协调工具Zookeeper（集群选举策略）

1.Zookeeper的角色

1. 领导者（leader） : 负责进行投票的发起和决议，更新系统状态
2. 学习者（learner） : 包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
3. Observer可以接受客户端连接 ：将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
4. 客户端（client）：请求发起方Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

2.Zookeeper的读写机制

• Zookeeper是一个主多个server组成的集群
• 一个leader，多个follower
• 每个server保存一份数据副本
• 全局数据一致
• 分布式读写
• 更新请求转发，由leader实施

3. Zookeeper的保证

• 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
• 数据更新原子性，一次数据更新要么成功，要么失败
• 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
• 实时性，在一定事件范围内，client能读到最新数据

4. Zookeeper leader 选举

半数通过:

• 3台机器 挂一台 2>3/2
• 4台机器 挂2台 2！>4/2
• A提案说，我要选自己，B你同意吗？C你同意吗？B说，我同意选A；C说，我同意选A。(注意，这里超过半数了，其实在现实世界选举已经成功了。

但是计算机世界是很严格，另外要理解算法，要继续模拟下去:

• 接着B提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；C说，A已经超半数同意当选，B提案无效。
• 接着C提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；B说，A已经超半数同意当选，C的提案无效。
• 选举已经产生了Leader，后面的都是follower，只能服从Leader的命令。而且这里还有个小细节，就是其实谁先启动谁当头。

5. Zookeeper 集群环境搭建

参考之前写的文章：《 Linux下Zookeeper集群环境搭建》