Zab系列博客
Raft Vs Zab
https://www.jianshu.com/p/24307e7ca9da
Zab系列1 核心概念
https://www.jianshu.com/p/76e5dba31ea4
Zab系列2 角色和存储
https://www.jianshu.com/p/d80f9250ffd1
Zab系列3 选举
https://www.jianshu.com/p/0d2390c242f6
Zab系列4 zookeeper特性
https://www.jianshu.com/p/08b62ca1fe4e
Zab系列5 选举恢复（源码分析）
https://www.jianshu.com/p/b6acd99921b7
Zab系列6 zk单机版工作原理
https://www.jianshu.com/p/ed45982b18b4
Zab系列7 集群工作原理Leader篇
https://www.jianshu.com/p/59240c36ba1b
Zab系列8 集群工作原理Follower篇
https://www.jianshu.com/p/8d7c7f1b2838
Node的状态和角色
https://www.cnblogs.com/EasonJim/p/7488484.html
- LOOKING：进入leader选举状态
- FOLLOWING：leader选举结束，进入follower状态
- LEADING：leader选举结束，进入leader状态
- OBSERVING：处于观察者状态
角色的转换
- 当一台Server启动时，它会首先处于LOOKING状态，此时会尝试找到一个leader，如果找到，那么就看看这个leader是不是就是它，如果不是的话，就转换为FOLLOWING/OBSERVING状态，如果是它，那么就转换为LEADING状态．
- 当处于FOLLOWING/OBSERVING状态的server检测到它跟它知道的leader失去联系时，就会重新进入到LOOKING状态，并尝试重新找一个leader.
- 同样，当处于LEADING状态的server发现它跟处于FOLLOWING状态的server失去联系时，也会进入到LOOKING状态并尝试重新找到一个leader
Observer观察者角色
Observers和follower非常类似，observer的优点
- 可以灵活的扩展zk集群，新增和减少observer不会触发重新选举
- 大幅提升读取的速度的同时，不会降低写的速度
- 一定程度上提升容灾率，因为Observer的宕机不会影响集群继续服务
Observers和follower的区别
- Observer没有vote和Ack Propose的功能
- Observer只会收到一个特殊的leader发来的 commit 消息，包括了commitZxid以及对应proposal，但是follower会收到2个消息，第一个proposal消息，第二个是只有LastZxid的commit消息
日志和快照
只有半数节点ACK后的Proposal才会生成事务日志，这个和Raft算法不同，只要生成了事务日志，那么该事务一定是半数通过了的事务操作
zk的持久化非常特殊，不仅仅保存所有的日志，而且也保存所有的快照。也就是默认是包含全部的数据，虽然理论上来说，只需要包含最新的快照文件，已经哪些未被打包进快照的日志
默认每当记满100000个，则事务日志执行flush操作，同时开启一个新的文件来记录事务日志。
比如data路径有几个文件 log.100001，log.200001，log.300001每当命令满100000个，同时会执行内存树的快照，snapshot.[lastProcessedZxid]作为文件名创建一个新文件，快照内容保存到该文件中，snapshot.100001
Zk的日志和快照相结合且不删除的模式，实现了既高效又高可恢复性的特质，因为快照文件异常，可以完全根据日志文件来恢复数据到内存树中，但是这样效率很低。但是容错性就增强了。系统在恢复数据时，获取100个快照文件，按照序号排序，优先加载最大Txid的快照，加载成功就不用继续加载之前的快照了，然后获得 lastProcessedTxid，根据这个id再去遍历日志文件，加载lastProcessedTxid后面的数据并且更新lastProcessedTxid的值
如果单纯只保存一个快照文件以及未打包进快照的日志的话，一旦有数据丢失或者生成异常，则内存树中的数据不可恢复
