Zookeeper集群（leader选举原理、数据同步流程）

Zookeeper集群

集群角色

• Leader：领导者

写操作的唯一调度者和处理者，保证集群事务处理的顺序性。
集群内部各个服务器的调度者。
对于所有涉及写操作和更新操作的请求，要统一转发给leader处理。

• Follower：跟随者

处理读操作请求，可以直接响应读请求。
转发写请求给Leader
参与集群Leader选举投票

• Observer：观察者

处理读操作请求，可以直接响应读请求。
转发写请求给Leader
不参与提交和选举投票
提升集群的读性能；可以跨数据中心部署（如北京和香港都使用Zookeeper集群，Leader在北京，如果香港的节点是Follower，写操作会同步Follower，延迟较高，可以将香港节点设置为Observer，不参与选举，不参与投票，仅处理读请求）

集群架构

leader节点可以处理 读写请求，follower只可以处理读请求。follower在接收到写请求时，会把写请求转发给leader处理。

Zookeeper数据一致性保证：

• 全局可线性化写入：先到达leader的写请求会被先处理，leader决定写请求的执行顺序。
• 客户端FIFO顺序：来自给定客户端的请求按照发送顺序执行。

Leader选举原理

Zookeeper的Leader选举存在两个阶段：服务启动时的Leader选举、运行过程中leader宕机。

在分析选举原理前，介绍几个重要的参数：

• 服务器ID（myid）：编号越大在选举算法中的权重越大
• 事务ID（zxid）：值越大说明数据越新，权重越大
• 逻辑时钟（epoch-logiclclock）：同一轮投票中的逻辑时钟是相同的，每投完一次值会增加。

选举状态：

• LOOKING：竞选状态
• FOLLOWING：随从状态，同步leader数据，参与投票
• OBSERVING：观察状态，同步leader数据，不参与投票
• LEADING：领导者状态

服务器启动时

每个节点启动的时候都进入LOOKING观望状态

1. 第一台服务器server1启动，进入LOOKING观望状态，无法进行leader选举
2. 第二台服务器server2启动，进入LOOKING状态，此时两台机器可以通信，开始进行leader选举
3. 每台server发出一个投票，都是投自己。
4. 将自己的投票发送给集群的其他机器。
5. 接收到来自各个服务器的投票后，首先校验该投票的有效性， 如检查是否本轮投票（epoch）、是否来自LOOKING状态的机器。
6. 处理收到的其他server的投票。针对每一次投票，都将其他服务器的投票和自己的投票进行对比，对比规则：
   • 优先比较epoch
   • 检查zxid，zxid比较大的服务器优先作为leader
   • 如果zxid相同，那么比较myid，myid较大的服务器作为leader服务器
7. 统计投票。每轮投票后，服务器统计投票信息，判断是否有过半机器收到相同的投票信息。
8. 改变服务器状态。一旦确定了Leader，每个服务器响应更新自己的状态。如果是follower，那么变更为FOLLOWING，如果是leader，状态更改为LEADING。此时server3继续启动，直接加入，变更自己的状态为FOLLOWING。

运行过程中

当集群中leader服务器出现宕机或者不可用情况时，整个集群无法对外提供服务，进入新一轮的leader选举。

1. 变更状态。leader挂后，所有非observer服务器将自身服务器的状态修改为LOOKING。
2. 每一个server发出一个投票。在运行期间，每个服务器上zxid可能不同。
3. 处理投票，规则和启动过程相同。
4. 统计结果。与启动过程规则相同。
5. 改变服务器状态。与启动过程相同。

数据同步流程

在Zookeeper中，主要依赖ZAB协议来实现分布式数据一致性。

ZAB协议分为两部分：消息广播、崩溃恢复。

消息广播

Zookeeper使用单一的主进程Leader来接收和处理客户端所有事务请求，并采用ZAB协议的原子广播协议，将事务请求以Proposal提议广播到所有的Follower节点，当集群中有半数以上的Follower节点进行了正确的ACK反馈，那么Leader就会向所有的Follower服务器发送commit消息，将此提案进行提交。这个过程可以简称为2pc事务提交，流程如下图：

Observer节点只负责同步Leader数据，不参与2PC数据同步过程。

崩溃恢复

在正常情况消息下广播能运行良好，但是一旦Leader服务器出现崩溃，或者由于网络原理导致Leader服务器失去了与过半的Follower的通信，那么就会进入崩溃恢复模式，需要选举出一个新的Leader服务器。在这个过程中可能会出现两种 数据不一致的隐患，需要通过ZAB协议的特性进行避免。

• Leader服务器刚提出proposal后，立即崩溃
• Leader服务器将消息commit发出后，立即崩溃

ZAB协议的恢复模式使用了以下策略：

• 选举zxid最大的节点作为新的leader
• 新leader将事务日志中尚未提交的消息进行处理