Zookeeper分布式一致性协议ZAB源码剖析

Zookeeper分布式一致性协议ZAB源码剖析

ZAB协议

• ZK的强一致性
  • ZK严格来讲并不是实时强一致性，而是写时强一致性，读时顺序一致性
• ZAB协议(原子广播协议)，Paxos算法的一种简化实现，包括两种基本模式
  • 消息广播
    • 消息广播过程中使用类似于2PC两阶段提交过程，对于写全部交给leader接收，然后leader再将这些数据打包成一个事务提案转发给其它follower，然后根据所有follower返回的ack进行确认，如果包括leader以内的半数以上节点成功响应后再进行提交
  • 崩溃恢复
    • 崩溃恢复分为2种场景
      • leader在转发数据给所有follower之后，还没来得及收到follower的ack就崩溃了
      • leader在收到ack并提交了自己，同时进行部分提交之后崩溃
    • 针对这些问题，ZAB定义了两个原则
      • 确保丢弃那些只在leader提出/复制，但没有提交的事务
      • 确保那些已经在leader提交的事务最终会被服务器提交
    • ZAB设计了一个选举算法能确保提交已经被leader提交的事务，同时丢弃已经被跳过的事务，针对这个要求，如果让leader选举算法能够保证新选举的leader拥有集群中所有机器zxid最大的事务，那么就能够保证这个新选举出来的leader一定具有所有已经提交的提案，而且这么做可以省去leader检查事务的提交和丢弃工作的这一步操作
• 问题: ZAB和Paxos算法的联系与区别
  • 相同点
    • 存在类似于2PC的操作，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位代表每代leader的唯一性，低32位代表每代leader中事务的唯一性，同时也能让follower通过高32位识别不同的leader，简化数据恢复流程
  • 基于策略：当follower连接上leader之后，leader会根据自己服务最后提交的zxid和follower上的zxid进行比对，比对结果要么回滚，要么和leader同步
• 问题: 什么是脑裂问题，ZK脑裂问题如何规避
  • 脑裂
    • 假如因为网络不稳定导致leader与followe通信失败，此时follower就会开始进行新的leader选举，假设已经选举出新的leader，此时网络恰好恢复，那个失联的leader此时又能保持通信，此时就会出现两个leader
  • 如果一个集群中有多个leader都可以进行写操作，会导致数据错乱
  • 可以通过2PC可以避免脑裂问题，ZK肯定不能同时让两个leader存在，新恢复过来的leader会和follower的操作一样，会跟新的leader进行通信，然后比较二者之间选举周期，对于选举周期值大的说明数据是最新的，此时会把新leader的数据进行同步覆盖并且更新内存以及状态置为looking，重新进行选举，如果此时已经有leader，就会将自己设为follower
  • 与Redis脑裂问题不同的是Redis不需要过半以上节点数据同步成功就能返回成功响应