Dubbo学习之Zookeeper原理
- 背景
- Zookeeper核心
- ZAB协议初识
- 1. 事务编号Zxid(事务请求计数器+epoch)
- 2. epoch
- 3. Zab协议有两种模式-恢复模式（选主）、广播模式（同步）
- 4. Zab协议四阶段
- ZAB 协议 JAVA 实现（FLE-发现阶段和同步合并为 Recovery Phase（恢复阶段））
- Zookeeper投票机制
- Zookeeper工作原理
- Znode有四种形式的目录节点
背景
学习dubbo的时候接触过zookeeper，但是一直没搞清楚他的原理是啥，趁着有点时间，自己深入学习一下顺便做一些总结方便日后回忆（好记性真的不如烂笔头）
Zookeeper核心
Zookeeper核心是原子消息传递机制(即原子广播)，该机制使所有服务器保持同步。实现这个机制的协议是ZAB协议。ZAB协议有两种模式，分别是恢复模式和广播模式。既然说到了ZAB协议我们就对他做个简单的认识吧
ZAB协议初识
1. 事务编号Zxid(事务请求计数器+epoch)
- 在ZAB(Zookeeper Atomic Broadcast,zookeeper原子协议广播)协议的事务编号Zxid设计中，Zxid是一个64位的数字，其中低32位是一个简单的单调递增的计数器，
针对客户端每一个事务请求，计数器加1；而高32位则代表Leader周期epoch的编号，每个当选产生一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志最大事务的ZXID，并从中读取epoch值，然后加1，以此作为新的epoch,并将低32位从0开始计数
疑问：如果计数器从零开始其他的文件目录节点会不会受影响？
2. epoch
- epoch: 可以理解为当前集群所处的年代或者周期，每个Leader就想皇帝，都有自己的年号，所以每次改朝换代，leader变更后，都会在前一个朝代的基础上加1。这样就算旧的Leader崩溃恢复之后，也没有人会听他的了，因为follow只会听从当前年代的leader的命令。
3. Zab协议有两种模式-恢复模式（选主）、广播模式（同步）
Zab有两种协议模式，他们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab进入恢复模式，当领导者被选出来，且大多数server完成了和Leader状态同步后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。
疑问：其他server如果同步没有完成，正好有客户端读到哪些没有同步的，不是会数据不一致吗？
4. Zab协议四阶段
Leader election（选举阶段-选出准Leader）
- Leader election(选举阶段)：节点在一开始都处于选举阶段，只要一个节点得到超过半数节点的票数，它就当选准Leader。只要到达广播阶段（broadcast）准Leader才会成为真正的Leader。这个阶段的目的就是为了选出
准Leader，然后进入下一阶段
Discovery(发现阶段-接收提议、生成epoch、接受epoch)
- Discovery（发现阶段）：在这个阶段。followers跟准leader进行通信，同步followers最近接收的事务提议。这个阶段的主要目的是发现当前大多数节点接收的最新提议，并且准leader生成新的epoch，让followers接受，更新他们的accepted Epoch
- 一个follower只会连接一个leader，如果有一个节点f认为另一个follower p是leader，f在尝试连接p时被拒绝，f在被拒后，就会进入重新选举阶段
Synchronization（同步阶段-同步 follower 副本）
- Synchronization（同步阶段）：同步阶段主要是利用Leader前一阶段获得的最新提议历史，同步集群中所有的副本。只有当大多数节点都同步完成，准leader才会成为真正的leader。follower只会接收Zxid比自己lastZxid大的提议。
Broadcast(广播阶段-leader 消息广播)
- Broadcast（广播阶段）：到了这个阶段，
Zookeeper 集群才能正式对外提供事务服务， 并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。
ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK，只需要得到超过半数的节点的 ACK 就 可以了。
留下疑问：ZAB协议核心是啥？1
ZAB 协议 JAVA 实现（FLE-发现阶段和同步合并为 Recovery Phase（恢复阶段））
协议的 Java 版本实现跟上面的定义有些不同，选举阶段使用的是 Fast Leader Election（FLE），
它包含了选举的发现职责。因为FLE会选举拥有最新提议历史的节点作为 leader，这样就省去了
发现最新提议的步骤。实际的实现将 发现阶段 和 同步合并为 Recovery Phase（恢复阶段）。所
以，ZAB 的实现只有三个阶段：Fast Leader Election；Recovery Phase；Broadcast Phase。
Zookeeper投票机制
每个Server首先给自己投票，然后用自己的选票和其他Server选票对比，使用权重较大的更新自身选票箱。 具体选举过程如下：
- 每个Server启动以后都询问其他的Sever它要投票给谁。对其他server询问，server每次根据自己的状态都恢复自己推荐的leader的id和上一次处理事务的Zxid（系统启动时每个人都会推荐自己）
- 收到所有server回复以后，就计算出Zxid最大的那个server，并将这个server相关信息设置成下一次要投票的server
- 计算过程中获得票数最多的server为获胜者，如果获胜者的票数超过半数，则改变server为leader。否则，继续这个过程，知道leader被选举出来
- leader开始等待server连接
- follower连接leader，将最大的Zxid发送给leader
- leader根据follower的Zxid确定同步点，至此选举阶段完成
- 选举阶段完成leader同步后通知follower已经成为uptodate状态
- follower收到uptodate消息后，又可以重新接受client的请求进行服务了
举个例子
目前5台服务器，每台服务器均没有数据，他们的编号分别是1,2,3,4,5，按编号启动他们。他们的选举过程如下：
- 服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反
馈信息，服务器 1 的状态一直属于 Looking。 - 服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号
大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是Looking。 - 服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编
号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器
1,2 成为小弟。 - 服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的
编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。 - 服务器 5 启动，后面的逻辑同服务器 4 成为小弟。
选举代码所在包目录
选举代码片段
// Zookeeper包FastLeaderElection类中的选举函数
public Vote lookForLeader() throws InterruptedException {
try {
// 初始化一个选举对象
this.self.jmxLeaderElectionBean = new LeaderElectionBean();
// 将这个初始化对象注册进CurrentHashmap
MBeanRegistry.getInstance().register(this.self.jmxLeaderElectionBean, this.self.jmxLocalPeerBean);
} catch (Exception var23) {
LOG.warn("Failed to register with JMX", var23);
this.self.jmxLeaderElectionBean = null;
}
if(this.self.start_fle == 0L) {
this.self.start_fle = Time.currentElapsedTime();
}
try {
HashMap recvset = new HashMap();
HashMap outofelection = new HashMap();
int notTimeout = 200;
// 更新提议（保证同步）
synchronized(this) {
this.logicalclock.incrementAndGet();
this.updateProposal(this.getInitId(), this.getInitLastLoggedZxid(), this.getPeerEpoch());
}
LOG.info("New election. My id = " + this.self.getId() + ", proposed zxid=0x" + Long.toHexString(this.proposedZxid));
// 通知所有的server我的提议
this.sendNotifications();
FastLeaderElection.Notification n;
// 获取当前peer状态为LOOKING并且服务没有停止
while(this.self.getPeerState() == ServerState.LOOKING && !this.stop) {
// 取出最先进入的元素，如果没有值则阻塞等待给定的时间，此处给的是notTimeout，单元为毫秒
n = (FastLeaderElection.Notification)this.recvqueue.poll((long)notTimeout, TimeUnit.MILLISECONDS);
// 没有通知
if(n == null) {
// 队列中还有连接信息
if(this.manager.haveDelivered()) {
this.sendNotifications();
} else {
// 去进行server连接
this.manager.connectAll();
}
int e1 = notTimeout * 2;
notTimeout = e1 < '\uea60'?e1:'\uea60';
LOG.info("Notification time out: " + notTimeout);
} else if(this.validVoter(n.sid) && this.validVoter(n.leader)) {
Vote e;
Vote var6;
//这个switch代码不是太清楚什么意思
switch(null.$SwitchMap$org$apache$zookeeper$server$quorum$QuorumPeer$ServerState[n.state.ordinal()]) {
case 1:
if(n.electionEpoch > this.logicalclock.get()) {
this.logicalclock.set(n.electionEpoch);
recvset.clear();
// 如果n的权重和Zxid比当前的大，使用n进行提议更新
if(this.totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, this.getInitId(), this.getInitLastLoggedZxid(), this.getPeerEpoch())) {
this.updateProposal(n.leader, n.zxid, n.peerEpoch);
} else {
this.updateProposal(this.getInitId(), this.getInitLastLoggedZxid(), this.getPeerEpoch());
}
this.sendNotifications();
} else {
if(n.electionEpoch < this.logicalclock.get()) {
if(LOG.isDebugEnabled()) {
LOG.debug("Notification election epoch is smaller than logicalclock. n.electionEpoch = 0x" + Long.toHexString(n.electionEpoch) + ", logicalclock=0x" + Long.toHexString(this.logicalclock.get()));
}
break;
}
if(this.totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, this.proposedLeader, this.proposedZxid, this.proposedEpoch)) {
this.updateProposal(n.leader, n.zxid, n.peerEpoch);
this.sendNotifications();
}
}
if(LOG.isDebugEnabled()) {
LOG.debug("Adding vote: from=" + n.sid + ", proposed leader=" + n.leader + ", proposed zxid=0x" + Long.toHexString(n.zxid) + ", proposed election epoch=0x" + Long.toHexString(n.electionEpoch));
}
recvset.put(Long.valueOf(n.sid), new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));
if(!this.termPredicate(recvset, new Vote(this.proposedLeader, this.proposedZxid, this.logicalclock.get(), this.proposedEpoch))) {
break;
}
while((n = (FastLeaderElection.Notification)this.recvqueue.poll(200L, TimeUnit.MILLISECONDS)) != null) {
if(this.totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, this.proposedLeader, this.proposedZxid, this.proposedEpoch)) {
this.recvqueue.put(n);
break;
}
}
if(n == null) {
this.self.setPeerState(this.proposedLeader == this.self.getId()?ServerState.LEADING:this.learningState());
e = new Vote(this.proposedLeader, this.proposedZxid, this.logicalclock.get(), this.proposedEpoch);
this.leaveInstance(e);
var6 = e;
return var6;
}
break;
case 2:
LOG.debug("Notification from observer: " + n.sid);
break;
case 3:
case 4:
if(n.electionEpoch == this.logicalclock.get()) {
recvset.put(Long.valueOf(n.sid), new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));
if(this.ooePredicate(recvset, outofelection, n)) {
this.self.setPeerState(n.leader == this.self.getId()?ServerState.LEADING:this.learningState());
e = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch);
this.leaveInstance(e);
var6 = e;
return var6;
}
}
outofelection.put(Long.valueOf(n.sid), new Vote(n.version, n.leader, n.zxid, n.electionEpoch, n.peerEpoch, n.state));
if(this.ooePredicate(outofelection, outofelection, n)) {
synchronized(this) {
this.logicalclock.set(n.electionEpoch);
this.self.setPeerState(n.leader == this.self.getId()?ServerState.LEADING:this.learningState());
}
e = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch);
this.leaveInstance(e);
var6 = e;
return var6;
}
break;
default:
LOG.warn("Notification state unrecognized: {} (n.state), {} (n.sid)", n.state, Long.valueOf(n.sid));
}
} else {
if(!this.validVoter(n.leader)) {
LOG.warn("Ignoring notification for non-cluster member sid {} from sid {}", Long.valueOf(n.leader), Long.valueOf(n.sid));
}
if(!this.validVoter(n.sid)) {
LOG.warn("Ignoring notification for sid {} from non-quorum member sid {}", Long.valueOf(n.leader), Long.valueOf(n.sid));
}
}
}
n = null;
return n;
} finally {
try {
if(this.self.jmxLeaderElectionBean != null) {
MBeanRegistry.getInstance().unregister(this.self.jmxLeaderElectionBean);
}
} catch (Exception var20) {
LOG.warn("Failed to unregister with JMX", var20);
}
this.self.jmxLeaderElectionBean = null;
LOG.debug("Number of connection processing threads: {}", Long.valueOf(this.manager.getConnectionThreadCount()));
}
}画出流程图：（待画出）
Zookeeper工作原理
前面铺垫了那么多的知识，就是为了能够更好的说清zookeeper原理，zookeeper原理可以分几个点
- zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议为Zab协议，Zab协议有两种模式，她们分别是恢复模式和广播模式
- 当服务启动或者在领导者崩溃后，Zab就进入恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步后，恢复模式就结束了
- 状态同步保证了leader和server具有相同的状态
- 一旦leader已经和多数follower进入了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进入状态同步，待到结束后，它也参与消息广播。zookeeper服务一直维持在broadcast状态，知道leader崩溃了或者leader失去了大部分的followers支持
- 广播模式需要保证proposal被按顺序处理，因为zookeeper采用了递增的事务id号（Zxid）来保证。所有的提议（proposal）都在被提出烦人低吼加上了Zxid
- 实现中Zxid是一个64位的数字，高32位用来记录leader的epoch号，每次选出一个leader都会出现一个新的epoch。低32位是个递增计数。
- 当leader崩溃或者leader失去大多数的follower，这个时候zookeeper进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。
Znode有四种形式的目录节点
- PERSISTENT：持久节点
- EPHEMERAL：临时节点
- PRESISTENT_SEQUENTIAL：持久化顺序编号目录节点
- EPHEMERAL_SEQUENTIAL：临时化顺序编号目录节点
- ZAB协议参考地址 ↩︎
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
