整体过程
当读请求,则当前节点获取;若是写请求,则转发给leader,leader提交事务前,则先广播事务,超过过半节点写入成功,则写请求被提交
一个关键问题是leader节点和follow节点的数据一致性如何保证。
ZAB 协议
zab协议主要解决集群中节点的数据一致性。
zab 协议介绍
ZAB 协议包含两种基本模式,分别是
- 崩溃恢复
当lead挂了,则通过崩溃恢复选择出新的leader和完成leader和过半的节点之间的数据同步。 - 原子广播
消息广播的实现原理
消息广播的过程实际上是一个简化版本的二阶段提交过程。
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;
}
