Zookeeper如何保证数据一致性

目录

前言

ZK是事务处理模式 

什么是ZAB协议

Zab协议中的Zxid

消息广播阶段工作流程

崩溃恢复阶段工作流程

ZAB和Paxos算法的联系与区别

---

 

前言

 

在分布式场景中，zk应用非常广泛：比如发布订阅、命名服务、配置中心、注册中心、分布式锁等。

zk提供了一个类似Linux文件系统的数据模型，和基于Watcher机制的分布式事件通知，这些特性都依赖zk的高容错数据一致性协议

 

ZK是事务处理模式 

 

zk通过ZAB协议保证分布式事务的最终一致性。ZAB(Zookeeper Atomic Broadcast原子广播协议)支持崩溃恢复，基于该协议zk实现了一种主备模式的系统架构来保持集群中各个副本间数据一致性

在zk集群中，所有客户端请求都是打到Leader节点，Leader节点处理完再同步到其他Follower节点。如果Follower或Leader崩溃，都会通过ZAB协议保证数据一致性。

 

 

什么是ZAB协议

 

ZAB协议具体分为2个部分：

消息广播阶段：

Leader节点接收事务提交，并且将新的请求广播给Follower节点，收集各个节点的反馈，决定是否进行Commit。

崩溃恢复阶段：

如果在同步过程中出现Leader宕机，会进入崩溃模式，重选Leader。崩溃阶段还包括书籍同步操作，同步集群中最新的数据，保证集群数据的一致性。

 

 

Zab协议中的Zxid

 

Zxid是Zab协议的一个事务编号，Zxid是一个64位数字。每当有一个新的Leader选举出现时，就会从这个Leader服务器上取出本地日志中最大的Zxid，并从中读取epoch(代际)值，然后+1作为新的周期ID。高32位表示每代Leader的唯一性，低32位代表每代Leader中事务的唯一性

 

 

消息广播阶段工作流程

 

这一阶段所有zk的事务请求都交给Leader处理，Leader将客户端事务请求转换为事务提议，并且将事务提议分发给集群中所有的Follower。完成广播后，Leader等待Follower的反馈，当有半数Follower反馈信息时，Leader再次向集群内的Follower广播Commit信息，收到Commit信息的Follower会提交之前的提议。

 

 

崩溃恢复阶段工作流程

 

1.Leader崩溃后，各个节点状态变更为Looking

2.各个Server节点都会发出一个投票，参与选举

3.集群接收来自各个服务器的投票，开始出了投票和选举。出了投票过程对比的是Zxid，谁的Zxid大谁就是Leader。如果Zxid一样，谁的Server id(就是zoo.cfg中的myid)大，随时Leader。

此外投票过程只要有节点收到了半数票数后，就是新的Leader。

4.选出新Leader后，Leader会发送一个同步请求，所有Follower同步新Leader的数据

 

 

ZAB和Paxos算法的联系与区别

 

Paxos的思想与ZAB的相同点

• 都存在一个Leader，多个Follower
• 都使用半数投票选举机制
• 都使用“代(epoch)”作为当前Leader的周期。Paxos同样有这个标识，叫做Ballot Number

 

Paxos的思想与ZAB的相同点

• Paxos是理论，ZAB是实践
• ZAB协议增加了崩溃恢复的功能