zookeeper的原理-数据同步

整体过程

当读请求,则当前节点获取;若是写请求,则转发给leader,leader提交事务前,则先广播事务,超过过半节点写入成功,则写请求被提交

image.png

一个关键问题是leader节点和follow节点的数据一致性如何保证。

ZAB 协议

zab协议主要解决集群中节点的数据一致性。

zab 协议介绍

ZAB 协议包含两种基本模式,分别是

1. 崩溃恢复
   当lead挂了,则通过崩溃恢复选择出新的leader和完成leader和过半的节点之间的数据同步。
2. 原子广播

消息广播的实现原理

消息广播的过程实际上是一个简化版本的二阶段提交过程。

image.png

1 leader节点将proposal消息发给所有的follower;follower则把proposal消息写入磁盘,写入成功后发ack;
2 当leader节点收到过半节点的ack后,向follower节点发送commit并在本地执行该命令,向连接的客户端返回成功;follower收到commit命令后,提交该消息。
问题:会存在某一个时刻follower节点和leader节点数据不一致。

崩溃恢复的实现原理

崩溃恢复做两件事:选举出新的 leader和数据同步。

哪些场景会导致数据不一致

已经被处理的消息不能丢

在follower节点没有收到commit请求,leader节点挂了。

被丢弃的消息不能再次出现

在leader生成Proposal消息后挂了,则该leader所在的机器重新启动时要忽略该消息。

解决办法

针对上述场景,leader选举算法要求是能够确保已经被 leader 提交的事务
Proposal 能够提交、同时丢弃已经被跳过的事务 Proposal。
1 选举的leader的服务器的zxid最大,就可以保证该机器拥有事务proposal,因为只有超过半数的机器发送ack后,leader才能发送commit提交。
2 zxid 是 64 位,高32位表示epoch,每经过一次leader选举,则epoch+1;低32位表示消息技术器,没收到一次消息则+1,新leader选举后则该值置为0;当老leader重启后,新leader会把它拥有的旧的epoch号但未被提交的Proposal删掉。

ZXID

表示事务id,zookeeper采用递增的事务id表示事务。所有的proposal都会加一个事务id。

数据同步包

public class QuorumPacket implements Record {
  private int type;
  private long zxid;
  private byte[] data;
}