7.zookeeper的ZAB协议

什么是ZAB协议

ZAB全称zookeeper Atomic Broadcast.借鉴了paxos算法.基于ZAB,zk只有一台服务器leader负责处理外部的写请求,然后leader将数据同步到其他的follower节点.同一时间对外只能存在一个leader.

• 消息广播
• 崩溃恢复

消息广播

1. 客户端发送写请求
2. leader将客户端的请求转化为事务proposal提案,同时为每一个proposal分配一个全局唯一的ID,zxid
3. leader为每个follower分配一个单独的队列,将需要广播的proposal依次放到队列中,通过FIFO策略对消息进行发送
4. follower收到leader发送的proposal后,首先以事务日志的方式写入本地磁盘,写入成功后向leader反馈ACK响应
5. leader接受到follower的ACK响应之后,认为消息发送成功,进而发送commit消息
6. leader向所有follower广播commit消息,同时自身完成事务提交.follower接受到leader的commit的消息会将上一条事务提交

崩溃恢复

一旦Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去了与过半 Follower的联系，那么就会进入崩溃恢复模式

异常情况

1. leader在提出proposal之后,leader宕机
2. leader的proposal提交了,并且过半的follower都响应了ACK,但是leader在commit消息发出前挂了

崩溃恢复的两个要求

1. 确保已经被leader提交提案的proposal,必须最终被所有follower服务器提交 (已经产生的提案follower必须执行)
2. 确保丢弃已经被leader提出的,但是没有提交proposal

leader选举

1. 新选举出来的leader不能包含未提交的proposal,即是新的leader必须都是已经了proposal的follower节点
2. 新选举的leader中含有最大的zxid.避免leader服务器检查proposal的提交和丢弃工作

数据恢复

1. leader选举完成之后,在正式工作之前(接受事务,提出新的proposal),leader服务器会首先确认事务日志中所有的proposal是否已经被集群中过半的服务器commit
2. leader服务器需要确保所有的follower能够接受到每一条事务的proposal,并且能将所有已经提交的事务proposal应用到内存数据中.等到follower将所有未同步的事务proposal都从leader同步过,并且应用到内存数据中以后,leader才会把follower加入可用follower队列中