Leader Election
| 问题 | Raft | ZAB |
|---|---|---|
| 检测Leader宕机 | Raft是由follower进行检测,follower在一定的时间内收不到Leader的心跳就会任务Leader宕机,follower自己会变成candidate. | ZAB的检测是Leader和follower仪器检测;Leader维护了Q的集合,当多数派集合不在超过半数的时候,Leader自动进入选举状态; follower和Leader之间有单独的tcp连接,如果超时收不到Leader的心跳也会进入选举状态. |
| 过期Leader的屏蔽 | Raft通过term来识别 | ZAB通过epoch来实现 |
| Leader选举的投票过程 | Raft每个选举周期每个节点只能投一票,选举失败后进入下一个投票周期; | ZAB在选举的时候会首先都选举自己,然后通过不停的更新投票的信息最终选出Leader |
Leader Election
| 问题 | Raft | ZAB |
|---|---|---|
| 选取Leader后的数据同步 | Raft通过AppendEntry RPC进行同步 | ZAB通过一个专门的Recovery Phase来做这个事情 |
| 新Leader对老Leader未commit数据的处理 | ZAB在Recovery Phase直接commit老Leader的数据 | |
| 对于新加入节点的数据同步 | Raft对这种情况,不会影响client的写请求; | ZAB对于新加入的节点要走一个Recovery Phase的流程,会影响client的写入 |
Client read
| 问题 | Raft | ZAB |
|---|---|---|
| stale read | Raft严禁stale read | Zk 默认情况下会出现 stale read，如果想避免 stale read 必须使用 sync() + read() |
网友评论