Zookeeper基础知识笔记-ZAB工作原理

Zookeeper 的核心是原子广播机制 （ZAB  Zookeeper Atomic Broadcast），这个机制保证了各个 server 之间的同步。 实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。

恢复模式

当服务启动或者在领导者崩溃后， Zab 就进入了恢复模式，当领导者被选举出 来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状 态同步保证了 leader 和 server 具有相同的系统状态。

广播模式

一旦 leader 已经和多数的 follower 进行了状态同步后，它就可以开始广播消息 了，即进入广播状态。这时候当一个 server 加入 ZooKeeper 服务中，它会在 恢复模式下启动， 发现 leader ，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。 ZooKeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。

服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、 OBSERVING。

（ 1 ） LOOKING ：寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有Leader ，因此需要进入 Leader 选举状态。

（ 2 ） FOLLOWING ：跟随者状态。表明当前服务器角色是 Follower 。

（ 3 ） LEADING ：领导者状态。表明当前服务器角色是 Leader 。

（ 4 ） OBSERVING ：观察者状态。表明当前服务器角色是 Observer 。(不参加选举投票的机器）

1. 选举机制

ServerID :  myId 集群的时候，自己写的file里面定义了自己是第几个

ZxId : 事务ID -->事务ID越大说明数据越新

Epoch: 逻辑时钟 （经过多少次选举投票次数）-->猜想投票次数越多，说明越稳定

1.1 需要投票情况：

1. 整个集群刚刚启动 （通常是中间那台机，例如3台机那就是第二台是leader，5台机那就是第三台是leader
2. 集群Leader 死了，再重新选举

a. 初始投票过程 （举例5台机）

1. 第一台机启动，自己给自己投票 （不够半数），状态是LOOKING
2. 第二台机启动，也是自己给自己投票，第一台发现myid比第二台机小，于是把票投给第二台，然而第二台机票数还是不够半数，第一第二台状态是LOOKING
3. 第三台阶启动，也是自己给自己投票，第一第二台发现myid比第三台机小，于是把票投给第三台，次数够半数票，第三台当选Leader, 状态为LEADING , 第一第二台状态转为FOLLOWING
4. 第四第五台机启动发现有Leader ，状态转为FOLLOWING

b. 运行过程投票

  主节点挂了，大家再进行选举，超过半数份额还是按原来5个为基数，必须3个同意才行

1. 投票需要按 Epoch>Zxid >MyId 来比较

2 崩溃恢复过程

1.运行时，Leader挂机，通过选举得到新的Leader

2.Follower 发起连接请求，将自己的信息发送给Leader （serverId 和epoch）

3.Leader 将最新的Epoch 发送给Follower

4.Follower 返回ACK 和带上数据（zxid 和最新epoch）

1. Leader 根据Zxid 同步数据去Follower (DIFF/ SNAP/ TRUNC)
2. Leader 收到半数Follower ACK 后，进入正常工作状态，集群启动完毕

同步数据的方式

1. DIFF, 如果没有不一样，不需要同步
2. TRUNC: 如果Leader 的Zxid 小于 Follower，Follower需要回退
3. COMMIT: Leader 的Zxid 大于Follower，发送Proposal 给Follower 提交执行
4. SNAP, Follower是全新启动的，需要全量同步