Zookeeper中的Raft
- Zookeeper简介
- Zab 协议
- 选举
- 崩溃恢复
- 广播
1. Zookeeper简介
ZooKeeper是一个分布式协调服务，可用于服务发现、分布式锁、分布式领导选举、配置管理等。
这一切的基础，都是ZooKeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。
既然是一个文件系统，就不得不提ZooKeeper是如何保证数据的一致性的，如何进行领导选举，以及数据监控和通知机制的语义保证。
Zookeeper中的共识机制是一种改进型的Raft协议。称为ZAB协议。
2. Zab 协议
Zab 协议分为三大块：
- 消息广播（boardcast）：Zab 协议中，所有的写请求都由 leader 来处理。正常工作状态下，leader 接收请求并通过广播协议来处理。
- 崩溃恢复（recovery）：当服务初次启动，或者 leader 节点挂了，系统就会进入恢复模式，直到选出了有合法数量 follower 的新 leader，然后新 leader 负责将整个系统同步到最新状态。
- 选举（Election）：Zab通过消息版本号选举出Leader来负责所在区域的写入工作。
3. 选举
- epoch：选举的轮数。
- zxid：事务id，值越大表示数据越新。
- server：服务器的标示id。
选 epoch 最大的，epoch 相等时，选 zxid 最大的。epoch 和 zxid 都相等，选择 server id 最大的。
节点在选举开始都默认投票给自己，当接收其他节点的选票时，会根据上面的条件更改自己的选票并重新发送选票给其他节点，当有一个节点的得票超过半数，该节点会设置自己的状态为 leading，其他节点会设置自己的状态为 following。
选举状态：
- LOOKING: 竞选状态
- FOLLOWING: 随从状态，同步 leader 状态，参与投票
- OBSERVING: 观察状态，同步 leader 状态，不参与投票
- LEADING: 领导者状态
4. 崩溃恢复
在正常情况消息广播情况下能运行良好，但是一旦 Leader 服务器出现崩溃，或者由于网络原理导致 Leader 服务器失去了与过半 Follower 的通信，那么就会进入崩溃恢复模式，需要选举出一个新的 Leader 服务器。在这个过程中可能会出现两种数据不一致性的隐患，需要 ZAB 协议的特性进行避免。
1、Leader 服务器将消息 commit 发出后，立即崩溃。此时选举 zxid 最大的节点作为新的 leader
2、Leader 服务器刚提出 proposal 后，立即崩溃。新 leader 还要将事务日志中尚未提交的消息进行处理。
5. 广播
广播的过程实际上是一个简化的二阶段提交过程：
- Leader 接收到消息请求后，将消息赋予一个全局唯一的 64 位自增 id，叫做：zxid，通过 zxid 的大小比较即可实现因果有序这一特性。
- Leader 通过先进先出队列（通过 TCP 协议来实现，以此实现了全局有序这一特性）将带有 zxid 的消息作为一个提案（proposal）分发给所有 follower。
- 当 follower 接收到 proposal，先将 proposal 写到硬盘，写硬盘成功后再向 leader 回一个 ACK。
- 当 leader 接收到合法数量的 ACKs 后，leader 就向所有 follower 发送 COMMIT 命令，同事会在本地执行该消息。
- 当 follower 收到消息的 COMMIT 命令时，就会执行该消息。
Zookeeper中的Raft