Zookeeper分布式一致性协议ZAB源码剖析
ZAB协议
ZK的强一致性
- ZK严格来讲并不是实时强一致性,而是写时强一致性,读时顺序一致性
ZAB协议(原子广播协议)
,Paxos算法的一种简化实现,包括两种基本模式
消息广播
- 消息广播过程中使用类似于P2C两阶段提交过程,对于写全部交给leader接收,然后leader再将这些数据打包成一个事务提案转发给其它follower,然后根据所有follower返回的ack进行确认,如果包括leader以内的半数以上节点成功响应后再进行提交
崩溃恢复
- 崩溃恢复分为2种场景
- leader在转发数据给所有follower之后,还没来得及收到follower的ack就崩溃了
- leader在收到ack并提交了自己,同时进行部分提交之后崩溃
- 针对这些问题,ZAB定义了两个原则
- 确保丢弃那些只在leader提出/复制,但没有提交的事务
- 确保那些已经在leader提交的事务最终会被服务器提交
ZAB设计了一个选举算法能确保提交已经被leader提交的事务,同时丢弃已经被跳过的事务
,针对这个要求,如果让leader选举算法能够保证新选举的leader拥有集群中所有机器zxid最大的事务,那么就能够保证这个新选举出来的leader一定具有所有已经提交的提案,而且这么做可以省去leader检查事务的提交和丢弃工作的这一步操作
- 崩溃恢复分为2种场景
问题
: ZAB和Paxos算法的联系与区别- 相同点
- 存在类似于P2C的操作,leader写,由leader协调其它followe运行
- leader会等待过半以上follower的ack之后再进行提案提交
- 每个提案中都包含一个周期值
- 不同点
- ZAB是用来构建高可用分布式主备系统的
- Paxos是用来构建分布式一致性状态机系统的
- 相同点
数据同步
- 当崩溃恢复后,需要在服务工作之前接收客户端请求,leader首先确认是否已经被过半follower提交了,也就是是否完成了数据同步,目的是为了保证数据一致性。当follower成功同步之后,leader会将这些服务加入到可用服务列表中。
问题
: leader服务处理或丢弃事务都是依赖着 ZXID 的,那么这个 ZXID 如何生成- zxid是一个64位的整数
- 低32位(事务Id)
- 可以看作是一个简单的递增计数器,针对客户端的每一个事务请求,leader都会产生一个新的事物提案并对计数器进行+1
- 高32位(leaderId)
- leader服务取出本地日志中最大事务提案的zxid,并从zxid中解析出对应的选举周期值,每轮选举之后,周期值都+1,并且事务id又从0开始
- 低32位(事务Id)
- 高32位代表每代leader的唯一性,低32位代表每代leader中事务的唯一性,同时也能让follower通过高32位识别不同的leader,简化数据恢复流程
- 基于策略:当follower连接上leader之后,leader会根据自己服务最后提交的zxid和follower上的zxid进行比对,比对结果要么回滚,要么和leader同步
- zxid是一个64位的整数
问题
: 什么是脑裂问题,ZK脑裂问题如何规避脑裂
- 假如因为网络不稳定导致leader与followe通信失败,此时follower就会开始进行新的leader选举,假设已经选举出新的leader,此时网络恰好恢复,那个失联的leader此时又能保持通信,此时就会出现两个leader
- 如果一个集群中有多个leader都可以进行写操作,会导致数据错乱
- 可以通过P2C可以避免脑裂问题,ZK肯定不能同时让两个leader存在,新恢复过来的leader会和follower的操作一样,会跟新的leader进行通信,然后比较二者之间选举周期,对于选举周期值大的说明数据是最新的,此时会把新leader的数据进行同步覆盖并且更新内存以及状态置为looking,重新进行选举,如果此时已经有leader,就会将自己设为follower
- 与Redis脑裂问题不同的是Redis不需要过半以上节点数据同步成功就能返回成功响应