zab协议

ZAB:

zookeeper Atomic Broadcast(zookeeper 原子广播)，支持崩溃恢复 ；zookeeer 通过zab 协议来保证分布式事务的最终一致性

基于zab 协议，zookeeper 集群中有如下几个角色

j角色	描述
领导者(leader )	负责投票的发起和决议，更新系统状态
学习者(learner)	包括两个 1.跟随者(follower)：接收客户端请求并返回结果，参与决议的投票； 2.观察者(observer):接收客户端请求并返回结果,但是不参与决议的投票，可理解为特殊的跟随者
客户端 (client)	求发起方

协议解析：

1. leader节点的选举机制：

在集群中，只有一个leader 节点， 并且通过快速领导者选举机制选举产生：
参考 [https://www.jianshu.com/p/9a325551f02c] zookeeper选举机制

2. 运行流程

运行流程

• . 客户端发起一个请求（ 写，更改操作）给服务器，如果接受的服务器为follower 节点， 会转发给leader节点
• . leader 节点接收到 请求后，会转化为事务proposal 提案， 并为每个prososal 分配一个全局的id ， 即zxid
• . leader 会为每个follower 节点分配一个队列(先进先出)，并将proposal 发送到队列中去
• . follower 节点接收对应的proposal ，将以事务日志的方式写入磁盘，成功后发送ack 应答给leader 节点
• . leader 节点收到半数以上节点的ack 应答后，即认为消息发送成功，发送commit给follower 节点
• . leader 节点广播发送commit 消息给follower, 自身也进行事务的提交，follower 接受commit 消息进行事务的最终提交

在上述的流程中主要包括如下：
a . follower ack 应答机制
对于leader 发出的提案， follower 接收到后都要做出ack 应答， 当leader 节点收到半数以上的follower ack ,此时提案才会到后续的最终commit

b . 2pc， 两阶段提交
-. 预提交(发起提议): leader 节点发起 proposal
-. follower ack 应答
-. 最终提交： leader 节点收到半数以上的ack 应答，才会发送最终的commit