京公网安备11010502063487号QuorumPeer 状态机实测:LOOKING → FOLLOWING/LEADING → discovery → synchronization → broadcast;杀掉 leader 后存活节点约 +5 ms 进入 LOOKING,约 +216 ms 选出新 leader,约 +340 ms 完成同步;LOOKING 时 srvr 不服务;旧 leader 重启后以 follower 加入。
五节点 Quorum 检查表:对每个节点发 srvr / mntr 汇总角色、zxid、连接数、synced_followers;杀 follower 时 leader 的 synced_followers 4 → 3;杀 leader 后选举期间所有存活节点「不服务」,新 leader 的 zxid epoch +1;ruok 不能代表能否服务。
Leader 选举过程实测(3 节点,杀 leader 5 次):新 leader 出现中位 345 ms,第一次写入成功中位 410 ms(范围 373–811 ms);日志里的 Notification 展示选票交换:先投自己,再按比较规则改投。
FastLeaderElection 的选票比较实测:先比 epoch、再比 zxid、最后比 sid——落后的高 sid 节点落选、有最新数据的节点当选(z35-1);全新集群 5 次启动都是 2 号当选(谁先凑够多数派取决于启动时机)。
Leader 重新选举实测:杀 leader 5 次,持续写 / 读的客户端遇到的最长中断:写中位 445 ms(最小 379 / 最大 713)、读中位 432 ms;选举期间读写一起不可用。
zxid 设计实测:64 位 = epoch(高 32 位)+ counter(低 32 位);写 3 个 znode counter +3;换 leader 后 epoch +1、counter 重新开始(0x100000004 → 0x200000001),后一任的 zxid 一定更大;数据目录里的 acceptedEpoch / currentEpoch 文件记录纪元。
ZXID 的 epoch 与 counter 实测:counter 数事务(create/set/delete 各 +1,multi 整体 +1,新建 + 关闭会话 +2,读 +0);每选出一任 leader epoch +1(2, 3, 4),counter 从 0 开始;没有多数派期间反复选举不增加 epoch,只有成功当选才 +1。
ZAB 一致性协议的三个阶段实测:用杀 leader 后新 leader 与 follower 的日志还原发现 → 同步 → 广播,discovery 约 110 ms、synchronization 约 10 ms;NEWLEADER / UPTODATE 消息可见,发现阶段的消息在 INFO 日志里看不到。
Proposal、事务日志与 Commit 实测:写 500 个 znode,每个 follower 收到 500 个 proposal 和 500 个 commit,leader 提交 500 次;暂停两个 follower 后提案 ack 不齐,数据对读者不可见,恢复后几毫秒内提交可见。
Proposal、Transaction、Commit 的关系实测:用 TxnLogToolkit 读 3 个节点的事务日志,27 条事务逐行完全相同(时间戳、会话 id、cxid、zxid);cxid 是客户端请求序号、zxid 是集群事务序号;multi 是日志里的一条事务。
ZAB 日志同步实测:follower 略微落后 → DIFF;数据被清空 → SNAP(整份快照);旧 leader 带着从未被确认的写重新加入时,新 leader 日志里「Cannot send TRUNC … peer zxid is from different epoch」并回退为 SNAP,那条未确认的写消失。
ZAB 崩溃恢复实测:持续写入时杀 leader 5 次,共 5890 个已确认的写入全部保留(丢失 0 个);每次崩溃时正在进行的请求得到 ConnectionLoss,5 个里有 3 个其实已经写入;恢复后三个节点 zxid 与数据一致。