什么是ZAB协议
ZAB全称zookeeper Atomic Broadcast.借鉴了paxos算法.基于ZAB,zk只有一台服务器leader负责处理外部的写请求,然后leader将数据同步到其他的follower节点.同一时间对外只能存在一个leader.
- 消息广播
- 崩溃恢复
消息广播
- 客户端发送写请求
- leader将客户端的请求转化为事务proposal提案,同时为每一个proposal分配一个全局唯一的ID,zxid
- leader为每个follower分配一个单独的队列,将需要广播的proposal依次放到队列中,通过FIFO策略对消息进行发送
- follower收到leader发送的proposal后,首先以事务日志的方式写入本地磁盘,写入成功后向leader反馈ACK响应
- leader接受到follower的ACK响应之后,认为消息发送成功,进而发送commit消息
- leader向所有follower广播commit消息,同时自身完成事务提交.follower接受到leader的commit的消息会将上一条事务提交
崩溃恢复
一旦Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去了与过半 Follower的联系,那么就会进入崩溃恢复模式
异常情况
- leader在提出proposal之后,leader宕机
- leader的proposal提交了,并且过半的follower都响应了ACK,但是leader在commit消息发出前挂了
崩溃恢复的两个要求
- 确保已经被leader提交提案的proposal,必须最终被所有follower服务器提交 (已经产生的提案follower必须执行)
- 确保丢弃已经被leader提出的,但是没有提交proposal
leader选举
- 新选举出来的leader不能包含未提交的proposal,即是新的leader必须都是已经了proposal的follower节点
- 新选举的leader中含有最大的zxid.避免leader服务器检查proposal的提交和丢弃工作
数据恢复
- leader选举完成之后,在正式工作之前(接受事务,提出新的proposal),leader服务器会首先确认事务日志中所有的proposal是否已经被集群中过半的服务器commit
- leader服务器需要确保所有的follower能够接受到每一条事务的proposal,并且能将所有已经提交的事务proposal应用到内存数据中.等到follower将所有未同步的事务proposal都从leader同步过,并且应用到内存数据中以后,leader才会把follower加入可用follower队列中