zookeeper的zab协议与Nacos的Raft协议

zab一致性算法原理，以zookeeper为例
zab原子广播协议中 两种模式
1.恢复模式：Leader宕机后选举新Leader
2.广播模式：解决每个节点数据同步问题
ZK每个节点都有myid(手动配置)和zxid(自动生成，默认为0)

zab类似paxos，但zab在生成全局zxid时会使用锁保存zxid线程安全

zk同步原理

Leader节点会生成全局zxid，然后通过两段提交协议进行同步
1.第一阶段同步，带上zxid请求每个follower节点是否可以允许同步数据
2.Leader节点接收到半数以上的节点可以同步,Leader节点就会开始给Follower进行同步数据

ZK选举底层实现原理：

1.先检查zxid，谁最大，谁就为Leader，因为zxid越大表示当前节点数据越新
2.如果zxid都一样的情况，myid最大的为leader

备注：zk的Observer(特殊的follower，只读，只监听同步，不参与投票选举(扩容时不影响本身选举的时候效率，能提高查询性能)

---

Raft协议

在Raft协议算法上角色有跟随者(不竞选领导角色)、竞选者(候选人)、领导角色
选举票数满足半数以上就会成为领导角色

选举过程：

默认情况下每个节点都为跟随者，每个节点会随机生成一个超时时间，大概100-300ms，超时时间这后，当前节点的状态就会由跟随者变为竞选者，会给其他节点发出选举投票通知，只要竞选者有超过半数以上的票，就成为领导角色
所以节点的超时时间最短，最有可能成为领导角色

故障选举过程

如果某跟随者节点不能及时收到领导角色的消息(心跳检测)，那么这个跟随者状态就会变为竞选者状态，给其他节点发出选举投票通知，其他节点确认领导角色挂了，就会进行投票，竞选者超过半数以上即可选举为领导角色

Raft采用日志复制形式同步数据

1.所有的写请求都是统一交给领导角色完成，会写入对应的日志，标记该状态为提交状态。
2.领导角色将日志以心跳的形式发送其他的跟随者，只要满足过半的跟随者可以写入数据，则直接通知其他节点同步该数据，这个称为日志复制