zk集群--集群同步

已于 2024-02-25 23:52:03 修改
阅读量1.2k 收藏 4
点赞数 5
分类专栏： 6.分布式-zookeeper 文章标签： zk 集群同步
于 2024-02-05 17:10:13 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/x13262608581/article/details/136044998
版权

1.概述

前面一章分析了集群启动阶段的选举过程，运行中重新开始选举和启动时的选举流程也是一致的．
一旦完成选举，通过执行QuorumPeer的setPeerState将设置好选举结束后自身的状态。然后，将再次执行QuorumPeer的run的新的一轮循环，

QuorumPeer的run的每一轮循环，先判断自身当前状态：
(1). 自身为LOOKING
则需在本轮循环开启选举，并完成选举。
(2). 自身为FOLLOWING

protected Follower makeFollower(FileTxnSnapLog logFactory) throws IOException {
    return new Follower(this, new FollowerZooKeeperServer(logFactory, this, this.zkDb));
}

try {
   LOG.info("FOLLOWING");
   setFollower(makeFollower(logFactory));
   follower.followLeader();
} catch (Exception e) {
    LOG.warn("Unexpected exception", e);
} finally {
    follower.shutdown();
    setFollower(null);
    updateServerState();
}

则应转换为从节点，先通过follower.followLeader();与主同步，再履行起从节点的角色任务。
(3). 自身为LEADING

protected Leader makeLeader(FileTxnSnapLog logFactory) throws IOException, X509Exception {
    return new Leader(this, new LeaderZooKeeperServer(logFactory, this, this.zkDb));
}
    
try {
    setLeader(makeLeader(logFactory));
    leader.lead();
    setLeader(null);
} catch (Exception e) {
    LOG.warn("Unexpected exception", e);
} finally {
    if (leader != null) {
        leader.shutdown("Forcing shutdown");
        setLeader(null);
    }
    updateServerState();
}

则应转换为主节点，先通过leader.lead();完成集群同步后，再履行起主节点的角色任务。

本部分讨论集群同步过程。集群同步是一个完成选举的主和从相互协作最终大家达成一致的过程。

2.集群同步过程最初的两次同步

2.1.利用同步确定新集群的轮次

2.1.1.主节点的leader.lead()

self.setZabState(QuorumPeer.ZabState.DISCOVERY);
self.tick.set(0);
zk.loadData();
leaderStateSummary = new StateSummary(self.getCurrentEpoch(), zk.getLastProcessedZxid());
cnxAcceptor = new LearnerCnxAcceptor();
cnxAcceptor.start();

上述动作里，先是设置ZabState为DISCOVERY。选举尚未结束时ZabState是ELECTION来着。
其中zk.loadData();由于在启动节点选举前已经执行过了一次基于快照+redo的数据实体恢复，所以这里啥也不用做。
构建一个StateSummary实例，这个实例反映了节点数据实体对应的轮次，lastZxid信息．
通过cnxAcceptor.start();使得主节点开始作为一个服务端，允许其他集群成员来连接以便执行集群同步及后续的请求处理。
对每个接入的集群成员，在主节点方面将通过accept得到通信套接字，并分配一个LearnerHandler来维护和集群成员的通信。

LearnerHandler fh = new LearnerHandler(socket, is, Leader.this);
fh.start();

fh.start();将开启一个线程，在此线程中将接收来自连接对端的包，并对其执行处理。
接下来，主节点执行的是：

long epoch = getEpochToPropose(self.getId(), self.getAcceptedEpoch());

主节点执行getEpochToPropose的目的是为了获得新产生的集群的轮次要设置为何值？
此处将产生同步等待，直到算上主节点自身，有半数以上集群成员连接到的主节点并执行了getEpochToPropose才能获得继续。继续时，将主节点的acceptedEpoch设置为所有执行getEpochToPropose的节点中acceptedEpoch最大值+1．
对主节点，此处的同步等待超时下，将引发主节点停止。并设置自身状态为LOOKING。这样，在QuorumPeer的run的新一轮循环里，将重新开始选举过程。

2.1.2.从节点的follower.followLeader()

self.setZabState(QuorumPeer.ZabState.DISCOVERY);
QuorumServer leaderServer = findLeader();
connectToLeader(leaderServer.addr, leaderServer.hostname);
connectionTime = System.currentTimeMillis();

上述动作里，先是设置ZabState为DISCOVERY。选举过程中ZabState是ELECTION来着。
然后，执行findLeader找到主节点。借助自身的投票和集群全局配置很容易定位出来。
connectToLeader将同步方式发起到服务端连接。
若指定时间或指定次数内连接未建立，将引发从节点停止。并设置自身状态为LOOKING。这样，在QuorumPeer的run的新一轮循环里，将重新开始选举过程。若连接成功，在异步发包下会启动一个线程用于异步发包。
从节点接下来执行：

long newEpochZxid = registerWithLeader(Leader.FOLLOWERINFO);

这里面从节点先向主节点发一个包

long lastLoggedZxid = self.getLastLoggedZxid();
QuorumPacket qp = new QuorumPacket();
qp.setType(Leader.FOLLOWERINFO);// 包类型
qp.setZxid(ZxidUtils.makeZxid(self.getAcceptedEpoch(), 0));// 包里的zxid
LearnerInfo li = new LearnerInfo(self.getId(), 0x10000, self.getQuorumVerifier().getVersion());
ByteArrayOutputStream bsid = new ByteArrayOutputStream();
BinaryOutputArchive boa = BinaryOutputArchive.getArchive(bsid);
boa.writeRecord(li, "LearnerInfo");
qp.setData(bsid.toByteArray());// 包的数据体是一个LearnerInfo实例。包含从节点sid，0x10000，集群全局信息。
writePacket(qp, true);

现在从节点等待主节点的回复。

2.1.3.主节点实现从节点接入及收包处理
主节点会为每个接入到其的从节点，分配一个LearnerHandler实例，此实例将占据一个独立的线程来执行对应从节点的数据包收取和处理。

LeaderHandler的run一开始执行：

learnerMaster.addLearnerHandler(this);

这样将向leader的learners集合中加入此LearnerHandler实例。
然后将开始收取首个包。并对首个包进行合法性检测（对从节点首个包类型必须是Leader.FOLLOWERINFO）。
若检测失败，服务端方面会停止线程，关闭被动连接，从leader的learners，forwardingFollowers，observingLearners集合移除此LearnerHandler实例。客户端方面则将引发从节点停止，并设置自身状态为LOOKING。这样，在QuorumPeer的run的新一轮循环里，将重新开始选举过程。后续分析过程失败过程处理类似。

检测通过后，对首个包进行解析

QuorumPacket qp = new QuorumPacket();
// 反向序列化获得包
ia.readRecord(qp, "packet");
byte[] learnerInfoData = qp.getData();// 获得包中数据体
ByteBuffer bbsid = ByteBuffer.wrap(learnerInfoData);
this.sid = bbsid.getLong();
this.version = bbsid.getInt(); // protocolVersion--0x10000
String followerInfo = learnerMaster.getPeerInfo(this.sid);
// 这样将获得从节点首个包里的zxid，从中提取出epoch
long lastAcceptedEpoch = ZxidUtils.getEpochFromZxid(qp.getZxid());
long peerLastZxid;
StateSummary ss = null;
long zxid = qp.getZxid();
long newEpoch = learnerMaster.getEpochToPropose(this.getSid(), lastAcceptedEpoch);

2.1.4. 集群同步阶段确定新集群的epoch
通过2.1.1到2.1.3我们知道。
选举结束后，主节点作为服务端允许集群从节点的接入。
然后，集群主节点将阻塞等待。
对每个结束选举的从节点，将连接主节点，成功后，发出首个Leader.FOLLOWERINFO包。然后等待回复。
主节点为每个接入的从节点分配LearnerHandler实例，并启动线程，处理收包和收包处理。
每个LearnerHandler的线程收取首个包Leader.FOLLOWERINFO后，通过learnerMaster.getEpochToPropose陷入与主节点一样的阻塞等待。

当算上主节点自身有半数以上成员陷入上述阻塞等待后，将基于所有等待成员中acceptedEpoch最大值+1作为新集群的epoch设置到leader的epoch。若上述过程某个成员连接上出现错误或等待超时，则将执行连接断开。此成员将停止其角色。重新变为LOOKING状态，重新进入选举过程。主节点自己等待超时或出错，则主节点停止作为主，重新变为LOOKING状态，并进入选举流程。主节点停止时会引发每个连到主节点的从节点也停止，并重新变为LOOKING状态。

2.2.利用同步再次确认选出的主是所有参与选举成员中状态最靠前的

我们分别针对主节点，从节点分析完成getEpochToPropose等待后的处理流程
2.2.1.对主节点

zk.setZxid(ZxidUtils.makeZxid(epoch, 0));
synchronized (this) {
    lastProposed = zk.getZxid();
}
newLeaderProposal.packet = new QuorumPacket(NEWLEADER, zk.getZxid(), null, null);
newLeaderProposal.addQuorumVerifier(self.getQuorumVerifier());
waitForEpochAck(self.getId(), leaderStateSummary);

主节点，后续执行waitForEpochAck。
主节点执行此步骤会阻塞，在waitForEpochAck中收集到半数以上的成员及其StateSummary后，且满足：
(1). 完成收集未引发超时
(2). 不存在从节点StateSummary领先主节点的情况。
上述两个条件，主节点将继续。并设置electionFinished为true。
若某个条件不满足，主节点将停止，并断开与连到其的从的连接，这样将引发从节点也停止。最终主，从均停止。并发起下一轮选举。

2.2.2.对从节点
分析LeaderHandler的run中后续动作

long newLeaderZxid = ZxidUtils.makeZxid(newEpoch, 0);
byte[] ver = new byte[4];
ByteBuffer.wrap(ver).putInt(0x10000);
QuorumPacket newEpochPacket = new QuorumPacket(Leader.LEADERINFO, newLeaderZxid, ver, null);
oa.writeRecord(newEpochPacket, "packet");
messageTracker.trackSent(Leader.LEADERINFO);
bufferedOutput.flush();// 立即发送
QuorumPacket ackEpochPacket = new QuorumPacket();
ia.readRecord(ackEpochPacket, "packet");

即给从节点回复一个Leader.LEADERINFO包，其中包含基于新集群epoch得到的zxid，版本信息(0x10000)。

从节点这边：

readPacket(qp);
final long newEpoch = ZxidUtils.getEpochFromZxid(qp.getZxid());// 取得回复包里的zxid
leaderProtocolVersion = ByteBuffer.wrap(qp.getData()).getInt();// 取得ver
byte[] epochBytes = new byte[4];
final ByteBuffer wrappedEpochBytes = ByteBuffer.wrap(epochBytes);
wrappedEpochBytes.putInt((int) self.getCurrentEpoch());// 放入自身currentEpoch
self.setAcceptedEpoch(newEpoch);// 用回复包里zxid导出的epoch设置自身acceptedEpoch
QuorumPacket ackNewEpoch = new QuorumPacket(Leader.ACKEPOCH, lastLoggedZxid, epochBytes, null);
writePacket(ackNewEpoch, true);// 向主节点发包
return ZxidUtils.makeZxid(newEpoch, 0);

即首先采用新集群的epoch设置自身的acceptedEpoch，再构造一个反映自身数据实体轮次，lastZxid的Leader.ACKEPOCH回复包执行回复．

继续分析LeaderHandler的run中

QuorumPacket ackEpochPacket = new QuorumPacket();
ia.readRecord(ackEpochPacket, "packet");// 等待从节点的回复
messageTracker.trackReceived(ackEpochPacket.getType());
ByteBuffer bbepoch = ByteBuffer.wrap(ackEpochPacket.getData());// 
ss = new StateSummary(bbepoch.getInt(), ackEpochPacket.getZxid());// 从节点的currentEpoch，从节点的zxid
learnerMaster.waitForEpochAck(this.getSid(), ss);

waitForEpochAck这个执行中将陷入等待。直到满足：
(1). 算上主自身有半数以上成员均针对主节点执行了waitForEpochAck。
(2). 收集到半数以上waitForEpochAck，未引发等待超时。
(3). 未出现某个从节点的ss领先于主节点的ss。
上述三者满足时，等待者和主节点继续运行。

若LearnerHandler中执行waitForEpochAck超时，将引发对应的从节点停止，并重新进入下一轮选举。
主节点完成waitForEpochAck这一同步后，将electionFinished设置为true。

到目前为止，我们分析了成员完成选举确认自身身份后，经历过了两个由主节点这边主导的阻塞等待。
第一个阻塞等待是getEpochToPropose，通过此等待基于所有连主成员中acceptedEpoch最大值+1作为新集群epoch。
此阶段，对从节点等待超时或出错，会使得其停止作为从，并重新进入选举。
此节点，对主节点等待超时或出错，会使得其自身和所有连到其的从均停止自身角色，并重新进入选举。
成功则，使得我们获得新集群的epoch，及基于epoch的zxid。

第二个阻塞等待是waitForEpochAck，通过此等待主要是再一次确认主节点的合法性。即主节点自身的进度确实是参与选举的各个节点中最靠前的。
比如一个1，2，3三个成员的集群。
(1). 1，2，3启动，并运行很长时间。
(2). 全部停止。
(3). 手动删除1，2的快照，redo。
(4). 启动1，2。使得1，2各自完成选举，预期2为主，1为从。
(5). 启动3，假设此时1，2各自处于waitForEpochAck。3选举结束，依据收到的Notification确定2为主。并连接2，也进入waitForEpochAck。此时就会产生某个从节点的状态领先主节点的情况。这时，就要使得主和从全部停止角色，并再次选举。再次选举，将选择3为主。此时，waitForEpochAck将获得通过。一旦主和从的waitForEpochAck结束。此时即使有新的从连到主，且领先于主，也不会被考虑了。

下面，将进入真正的集群同步阶段。

3. 真正的集群同步

我们继续分别从主节点，从节点角度分析其后续流程。
3.1. 主节点

self.setCurrentEpoch(epoch);
self.setLeaderAddressAndId(self.getQuorumAddress(), self.getId());
self.setZabState(QuorumPeer.ZabState.SYNCHRONIZATION);
waitForNewLeaderAck(self.getId(), zk.getZxid());

只有完成前述两个阶段的同步，且未出错。主节点才将新集群的epoch设置到其currentEpoch中。
注意，对主节点和从节点，只要其完成了前述中第一个同步，就会各自设置自己的acceptedEpoch。
所以，accepted反映的是集群完成选举且形成新的集群轮次的次数。（一个完成选举，形成集群轮次的集群并不一定可以成为对外服务的集群。必须继续完成前述第二个同步，并完成这里要讨论的实际的集群同步才可以。）

主节点执行waitForNewLeaderAck是我们遇到的新集群形成中主节点主导的第三次同步。
为了理解这个同步的意义，我们需要先分析，从节点方面在第二个同步完成后的后续动作．

3.2.从节点
先分析LearnerHandler的run中后续处理
这部分处理可以描述为：
(1). 从节点与主节点数据实体同步．
这一步是同步的关键所在，按从节点中数据实体lastZxid和主节点中数据lastZxid的情况．
有三种同步类型：
a. 快照同步
b. 差异化同步
c. 截断同步

我们下面分别对其分析．
对每种同步类型，我们分别分析此类型下的同步模式，然后给出一种会采用此种同步类型的实际场景．

a. 快照同步
a.1.同步模式
先发送一个new QuorumPacket(Leader.SNAP, zxidToSend, null, null)这样的包，其中zxidToSend是主节点数据实体的lastZxid．
在此包的数据体中发送主节点数据实体序列化后的内容．
a.2.何时采用
若从节点数据实体的lastZxid落后于主节点数据实体的lastZxid，且落后的较多时，采用快照同步．

b.差异同步
b.1.同步模式
先发送一个new QuorumPacket(Leader.DIFF, lastZxid, null, null);这样的包，其中lastZxid是主节点数据实体的lastZxid．
然后针对主节点领先于从节点的每个redo项，先发送一个此redo项对应的QuorumPacket，再发送一个new QuorumPacket(Leader.COMMIT, packetZxid, null, null);
b.2.何时采用
若从节点数据实体的lastZxid落后于主节点数据实体的lastZxid，但落后的不多时，采用差异同步．

c.截断同步
c.1.同步模式
发送一个new QuorumPacket(Leader.TRUNC, lastZxid, null, null);这样的包，其中lastZxid是主节点数据实体的lastZxid．
c.2.何时采用
若从节点数据实体的lastZxid领先于主节点数据实体的lastZxid，采用截断同步．
会出现此场景的一个实例：
假设１，２，３是集群三个节点．
时刻一，１，２，３分别启动构成集群并处理１０个请求．
时刻二，１，２，３分别停止．
时刻三，手动清理１，２．
时刻四，启动１，２构成集群并处理４个请求．
时刻五，３启动，并加入集群，在３的集群同步阶段即触发此场景．

(2). 将主节点中已经提交但尚未落入数据实体的各个请求，按发送一个此请求对应的QuorumPacket，再发送一个new QuorumPacket(Leader.COMMIT, packetZxid, null, null);的方式实现请求在从节点上的提交．
(3). 将主节点中提议但尚未提交的请求中领先于从节点的提议发送给从节点．
(3). 给从节点发送Leader.NEWLEADER包．

然后执行：

qp = new QuorumPacket();
ia.readRecord(qp, "packet");
learnerMaster.waitForNewLeaderAck(getSid(), qp.getZxid());

我们接着分析从节点对收到的这些包的处理。

3.3.从节点对集群同步包的处理
从节点在registerWithLeader后执行的流程为：

// 取得新集群epoch
long newEpoch = ZxidUtils.getEpochFromZxid(newEpochZxid);
if (newEpoch < self.getAcceptedEpoch()) {
    throw new IOException("Error: Epoch of leader is lower");
}
long startTime = Time.currentElapsedTime();
self.setLeaderAddressAndId(leaderServer.addr, leaderServer.getId());
self.setZabState(QuorumPeer.ZabState.SYNCHRONIZATION);
syncWithLeader(newEpochZxid);
self.setZabState(QuorumPeer.ZabState.BROADCAST);

从节点点在syncWithLeader里，会具体处理来自主节点的用于集群同步的包，实现和主节点的同步．
类似前面分析过程，我们以下分别分析采用DIFF，TRUNC，SNAP三种同步方式下，从节点在syncWithLeader中所作的针对性处理．
(1). DIFF同步
首先DIFF下，主节点给从节点发的包按按顺序分为以下几类：
a. 首个DIFF包
b. 后续若干和DIFF配套的PROPOSAL+COMMIT
c. 后续若干主节点中已经提交但尚未落地到数据实体的PROPOSAL+COMMIT
d. 主节点中处于提议阶段的若干PROPOSAL
e. 标志同步最后一个包的NEWLEADER

从节点的处理策略是：
a. 用packetsCommitted收集上述b，c类型里的每个PROPOSAL包
b. 用packetsNotCommitted收集上述b，c，d类型里的每个PROPOSAL包
这里值得注意的是b，c类型的包，既出现在packetsCommitted容器，又出现在packetsNotCommitted容器．
c. 针对NEWLEADER包的处理为：

self.setCurrentEpoch(newEpoch);// 只有同步结束，才能设置自身currentEpoch
writeToTxnLog = true;
isPreZAB1_0 = false;
sock.setSoTimeout(self.tickTime * self.syncLimit);
self.setSyncMode(QuorumPeer.SyncMode.NONE);
zk.startupWithoutServing();
if (zk instanceof FollowerZooKeeperServer) {
    FollowerZooKeeperServer fzk = (FollowerZooKeeperServer) zk;
    for (PacketInFlight p : packetsNotCommitted) {
        fzk.logRequest(p.hdr, p.rec, p.digest);
    }
    packetsNotCommitted.clear();
}
writePacket(new QuorumPacket(Leader.ACK, newLeaderZxid, null, null), true);

主要的处理是将packetsNotCommitted中的每个包执行持久化到日志文件的处理，且给主节点发送Leader.ACK．

(2). TRUNC同步
首先TRUNC下，主节点给从节点发的包按按顺序分为以下几类：
a. 首个TRUNC包
b. 后续若干主节点中已经提交但尚未落地到数据实体的PROPOSAL+COMMIT
c. 主节点中处于提议阶段的若干PROPOSAL
d. 标志同步最后一个包的NEWLEADER

从节点的处理策略是：
a. 针对TRUNC包的处理为：
按包中lastZxid，截断自身redo日志，使得自身领先部分被移除．
重新基于redo和快照加载数据实体，并设置其lastZxid．这样就实现了数据实体的同步效果．
b. 针对上述b类型的PROPOSAL+COMMIT每对包处理策略是：
对PROPOSAL，将其放入packetsNotCommitted
对COMMIT，将其从packetsNotCommitted移除，并直接在数据实体上迭代这个包．
c. 针对上述c类型的PROPOSAL包处理策略是：
对PROPOSAL，将其放入packetsNotCommitted
d. 针对d中NEWLEADER包处理策略是：

zk.takeSnapshot(syncSnapshot);
self.setCurrentEpoch(newEpoch);
writeToTxnLog = true;
isPreZAB1_0 = false;
sock.setSoTimeout(self.tickTime * self.syncLimit);
self.setSyncMode(QuorumPeer.SyncMode.NONE);
zk.startupWithoutServing();
if (zk instanceof FollowerZooKeeperServer) {
    FollowerZooKeeperServer fzk = (FollowerZooKeeperServer) zk;
    for (PacketInFlight p : packetsNotCommitted) {
        fzk.logRequest(p.hdr, p.rec, p.digest);
    }
    packetsNotCommitted.clear();
}
writePacket(new QuorumPacket(Leader.ACK, newLeaderZxid, null, null), true);

主要的处理为：为数据实体生成快照来实现已经处理部分持久化存储，将提议部分序列化到日志文件，给主节点发送ACK．

(3). SNAP同步
首先SNAP下，主节点给从节点发的包按按顺序分为以下几类：
a. 首个SNAP包
b. 后续若干主节点中已经提交但尚未落地到数据实体的PROPOSAL+COMMIT
c. 主节点中处于提议阶段的若干PROPOSAL
d. 标志同步最后一个包的NEWLEADER

从节点的处理策略是：
a. 针对SNAP包的处理为：
对包的数据部分执行反向序列化来重新构建自身的数据实体，从而达到同步效果．
b. 针对上述b类型的PROPOSAL+COMMIT每对包处理策略是：
对PROPOSAL，将其放入packetsNotCommitted
对COMMIT，将其从packetsNotCommitted移除，并直接在数据实体上迭代这个包．
c. 针对上述c类型的PROPOSAL包处理策略是：
对PROPOSAL，将其放入packetsNotCommitted
d. 针对d中NEWLEADER包处理策略是：

zk.takeSnapshot(syncSnapshot);
self.setCurrentEpoch(newEpoch);
writeToTxnLog = true;
isPreZAB1_0 = false;
sock.setSoTimeout(self.tickTime * self.syncLimit);
self.setSyncMode(QuorumPeer.SyncMode.NONE);
zk.startupWithoutServing();
if (zk instanceof FollowerZooKeeperServer) {
    FollowerZooKeeperServer fzk = (FollowerZooKeeperServer) zk;
    for (PacketInFlight p : packetsNotCommitted) {
        fzk.logRequest(p.hdr, p.rec, p.digest);
    }
    packetsNotCommitted.clear();
}
writePacket(new QuorumPacket(Leader.ACK, newLeaderZxid, null, null), true);

主要的处理为：为数据实体生成快照来实现已经处理部分持久化存储，将提议部分序列化到日志文件，给主节点发送ACK．

3.4.主节点这边收到Leader.ACK时处理
即LearnerHandler的run中同步后的处理：

qp = new QuorumPacket();
ia.readRecord(qp, "packet");
LOG.debug("Received NEWLEADER-ACK message from {}", sid);
learnerMaster.waitForNewLeaderAck(getSid(), qp.getZxid());
sock.setSoTimeout(learnerMaster.syncTimeout());
learnerMaster.waitForStartup();
queuedPackets.add(new QuorumPacket(Leader.UPTODATE, -1, null, null));

即，先通过waitForNewLeaderAck进入主节点主导的第三次同步．
当算上主节点自身，有半数以上成员执行了learnerMaster.waitForNewLeaderAck时，表示半数以上成员已经达成集群同步．
这意味着，此时集群才算正式启动，可以启动服务端面向外部客户提供接入和请求处理服务．

上述在等待主节点的面向外部客户的服务端启动后，给从节点发送Leader.UPTODATE包．
3.5.从节点收到Leader.UPTODATE包的处理

self.setZooKeeperServer(zk);
self.adminServer.setZooKeeperServer(zk);
ack.setZxid(ZxidUtils.makeZxid(newEpoch, 0));
writePacket(ack, true);
zk.startServing();
self.updateElectionVote(newEpoch);
if (zk instanceof FollowerZooKeeperServer) {
    FollowerZooKeeperServer fzk = (FollowerZooKeeperServer) zk;
    for (PacketInFlight p : packetsNotCommitted) {
        fzk.logRequest(p.hdr, p.rec, p.digest);
    }
    for (Long zxid : packetsCommitted) {
        fzk.commit(zxid);
    }
}

上述过程可简要描述为：
a. 从节点面向外部客户的服务端启动，允许外部客户接入并提供请求处理服务
b. 再次给主节点发送Ack
c. 更新自身集群选票中的currentEpoch
d. 对packetsNotCommitted，packetsCommitted中尚且存在的包，分别执行序列化和提交操作．
DIFF模式下，此时完成实际的同步处理．

此后进入从节点常规运行阶段：

self.setZabState(QuorumPeer.ZabState.BROADCAST);
completedSync = true;
QuorumPacket qp = new QuorumPacket();
while (this.isRunning()) {
    readPacket(qp);
    processPacket(qp);
}

这样从节点已经完成集群同步，且集群已经开始对外提供服务了．

3.5.主节点的后续
(1). LearnerHandler的run()中的后续
LearnerHandler的run中后续进入常规的事件循环．
在事件循环里先收集来自从节点的包，再对包执行处理．

(2). Leader的lead()的后续

startZkServer();// 起点服务端，开启外部服务
self.setZooKeeperServer(zk);
self.setZabState(QuorumPeer.ZabState.BROADCAST);
self.adminServer.setZooKeeperServer(zk);
boolean tickSkip = true;
String shutdownMessage = null;
while (true) {
	synchronized (this) {
	    long start = Time.currentElapsedTime();
        long cur = start;
        long end = start + self.tickTime / 2;
        while (cur < end) {
	        wait(end - cur);
            cur = Time.currentElapsedTime();
        }
        if (!tickSkip) {
	        self.tick.incrementAndGet();
        }
        SyncedLearnerTracker syncedAckSet = new SyncedLearnerTracker();
        syncedAckSet.addQuorumVerifier(self.getQuorumVerifier());
        syncedAckSet.addAck(self.getId());
        for (LearnerHandler f : getLearners()) {
        	if (f.synced()) {
	            syncedAckSet.addAck(f.getSid());
            }
        }
        if (!this.isRunning()) {
        	shutdownMessage = "Unexpected internal error";
            break;
        }
        if (!tickSkip 
        	&& !syncedAckSet.hasAllQuorums() 
        	&& !(self.getQuorumVerifier().overrideQuorumDecision(getForwardingFollowers()) 
        	&& self.getQuorumVerifier().revalidateOutstandingProp(this, 
        		new ArrayList<>(outstandingProposals.values()), lastCommitted))) {
	        shutdownMessage = "Not sufficient followers synced, only synced with sids: [ " 
	        	+ syncedAckSet.ackSetsToString() + " ]";
            break;
        }
        tickSkip = !tickSkip;
	}
  
  	for (LearnerHandler f : getLearners()) {
  		f.ping();
  	}
}
if (shutdownMessage != null) {
	shutdown(shutdownMessage);
}

这样，主节点方面也已经完成集群同步，且集群已经开始对外提供服务了．
且Leader的lead()后续会定期检测与主同步的节点数量，在节点数量不足半数时，停止主，并与所有连到其的从节点断开连接．这样，这些节点包含主自身将再次进入集群选举阶段．

raindayinrain
关注
  • 5
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
一键安装伪分布式zk集群-solr集群脚本
12-20
标题中的“一键安装伪分布式zk集群-solr集群脚本”指的是使用自动化脚本来部署Zookeeper集群和Solr集群，这种部署方式简化了传统手动安装的复杂过程，适合初学者和快速测试环境。Zookeeper是一个分布式协调服务，而...
ZK Book-开源
07-01
《ZK Book-开源》是关于ZooKeeper（ZK）的一款开源文档，它深入探讨了这个分布式协调服务的核心概念和技术细节。ZooKeeper是由Apache软件基金会开发的一个开放源码项目，广泛应用于分布式系统，如大数据处理、配置...
ClickHouse ZK集群迁移
一条大河
03-23 4144
CilckHouse迁移Zookeeper集群
ansible-playbook部署zookeeper集群
ledrsnet的博客
08-14 952
ansible-playbook部署zookeeper集群 https://gitee.com/liangsircc/my-ansible-example/tree/main/zookeeper_cluster 目录结构 root@mq1:~/my-ansible-example/zookeeper_cluster# tree . ├── ansible.cfg ├── hosts ├── roles │ └── zknode │ ├── files │ │ └── zoo.
k8s部署zk集群
包泽旭
04-28 1215
k8s 部署zk 集群 1. 环境介绍 使用helm 进行部署zookeeper：3.7 2. zk集群部署 helm repo add bitnami https://charts.bitnami.com/bitnami 3.创建zk集群 #首先使用fetch进行拉取chart helm fetch bitnami/zookeeper #将拉取下zk的压缩包进行解压 tar ...
ZooKeeper系列 —— ZK集群部署配置
一别两宽丶各生欢喜
02-07 2125
目录 1、zk服务介绍 ​2、部署配置zk服务 3、安装JDK1.8 4、启动zk集群 1、zk服务介绍 2、部署配置zk服务 [root@k8s-master2 ~]# mkdir /opt/module [root@k8s-master2 ~]# tar -zxvf zookeeper-3.4.10.tar.gz -C /opt/module/ [root@k8s-master2 ~]# cd /opt/module/zookeeper-3.4.10/conf/ # 默认只有一个模
docker-compose快速搭建Zookeeper集群
每个人都是独一无二的，把握好自己的节奏，跟着自己的心走。
08-24 1603
之前手动去搭建zookeeper集群的需要对两个配置文件进行配置如下：1、配置myid文件，表示唯一的服务标号。100在docker compse中我们可以直接在配置文件中指定即可。
DolphinScheduler-3.2.0集群部署教程
扛麻袋的少年的博客
01-19 2147
海豚调度 DolphinScheduler 3.2.0 集群部署教程
zk集群的选举和数据的同步
qq_42987796的博客
01-07 1231
zab协议 zookeeper为了保证数据的⼀致性，使⽤了ZAB（Zookeeper Atomic Broadcast）协议，这个协议解决了Zookeeper的崩溃恢复和主从数据同步的问题。 集群的选举 集群刚启动的时候 在集群启动的时候，每个结点都会生成一张自己的选票，之后各个机器之间会将自己的选票发给其他机器，机器在拿到其他机器的选票的时候，会先对比选票中的事务id，事务id大的成为主节点的权重也更大，如果事务id都是一致的话，那么对比每台机器的serviceid,结点会选出一张最合理的选票，投到选票箱
zk的集群搭建
健康平安的活着的专栏
02-06 3943
一 集群规划描述 192.168.152.128 master 192.168.152.129 slaver01 192.168.152.130 slaver02 安装包存放的目录：/ bigdata-software 安装程序存放的目录：/export/servers 三台机器执行以下命令创建统一文件目录 mkdir -p /export/servers mkdir -p /export/ bigdata-soft...
HBASE安装-同步集群时间
X043800的博客
08-27 740
1.HDFS启动 start-all.sh 2. ZooKeeper集群启动 单节点启动: zookeeper-3.4.6/bin/zkServer.sh start 3.同步集群时间---时间不同步会抛出异常 1. 连接时间服务器同步集群时间 yumyum -y install ntpdate.x86_64 ntpdate 0.asia.pool.ntp.org 2.手动设置时间 date -s ''2020-08-27-19:2...
zk-bin-3.6.2.zip_zk_zk version 3_zk-bin-5.0.2
09-14
它提供了命名服务、配置管理、组服务、分布式同步和领导者选举等功能。 在ZooKeeper中，"zk-bin"通常指的是二进制发行版，包含了运行ZooKeeper服务器和客户端所需的可执行文件、配置文件以及脚本。3.6.2和5.0.2是...
zk-manager.zip
09-02
ZK Manager 是一款专为Zookeeper设计的管理工具，它使得对Zookeeper集群的监控、管理和操作变得更加便捷。Zookeeper，一个分布式的，开放源码的分布式应用程序协调服务，是Apache Hadoop的重要组成部分，广泛应用于...
zk-bin-7.0.3.zip
11-28
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它是集群的必备组件，可以提供诸如命名服务、配置管理、集群同步、分布式锁等服务。这个zip文件包含运行和管理ZooKeeper所需的所有基本组件。 在描述...
Flash动作脚本技术(FAS程序设计项目化教程--项目七--金苑五笔打字训练系统).doc
07-23
flash
毕业设计项目之基于Opencv的车牌识别系统项目源码
最新发布
07-23
毕业设计项目之基于Opencv的车牌识别系统项目源码 版本：python3.7.3，opencv4.0.0.21，numpy1.16.2，tkinter和PIL5.4.1.
MSP4305529控制AD9833(DDS模块)
07-23
采用TI单片机MSP4305529LP来控制DDS模块产生正弦信号方波信号三角波信号或正弦扫频信号
连接器连接口装配机_包括零件图_机械3D图可修改打包下载.zip
07-23
连接器连接口装配机_包括零件图_机械3D图可修改打包下载.zip
linux下zookpeeper如何同步集群配置文件得
07-17
在 Linux 下，你可以使用 ZooKeeper 的命令行工具（zkCli）来同步集群配置文件。 首先，确保你已经在每个节点上安装了 ZooKeeper，并且启动了 ZooKeeper 服务器。 然后，你可以在任意一个节点上使用以下命令启动 zkCli： ``` $ zkCli.sh ``` 接下来，连接到 ZooKeeper 服务器： ``` [zkshell: localhost:2181(CONNECTED) 0] ``` 现在，你可以使用 ZooKeeper 的命令来操作配置信息的 znode。首先，创建一个用于存储配置信息的 znode： ``` [zkshell: localhost:2181(CONNECTED) 0] create /config "" ``` 这会在根目录下创建一个名为 config 的 znode。你可以使用 set 命令来修改这个 znode 的值，即更新配置信息： ``` [zkshell: localhost:2181(CONNECTED) 1] set /config "your_configuration_data" ``` 这会将配置信息更新为 "your_configuration_data"。所有监听了这个 znode 的客户端都会收到通知，并获取到最新的配置信息。 如果你想查看当前配置信息的值，可以使用 get 命令： ``` [zkshell: localhost:2181(CONNECTED) 2] get /config ``` 这会返回当前配置信息的值。 通过以上步骤，你可以在 Linux 下使用 zkCli 来同步集群配置文件。记得在每个节点上都执行相同的操作，确保所有节点都能够获取到最新的配置信息。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

raindayinrain

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值