ZooKeeper 避坑实践： Zxid溢出导致选主

作者：子葵

背景

线上 flink 用户使用 ZooKeeper 做元数据中心以及集群选主，一些版本的 flink 在 ZooKeeper 选主时，会重启 Job，导致一些非预期的业务损失。而 ZooKeeper 在 zxid溢出时，会主动触发一次选主，就会导致 flink Job 的非预期重启，造成业务损失。本篇从原理和最佳实践上分析和解决由于 ZooKeeper zxid 溢出导致的集群选主问题。检查 ZooKeeper Server 日志出现。

zxid lower 32 bits have rolled over, forcing re-election, and therefore new epoch start

解决方法

ZooKeeper 本身提供当前处理的最大的 Zxid，通过 stat 接口可查看到当前处理的最大的 zxid 的值，通过此值可以计算当前 zxid 距离溢出值还有多少差距。MSE 提供风险管理以及集群选主相关告警，提前预防和及时感知选主风险，避免业务损失。

通过 MSE ZooKeeper 风险管理和集群选主时间告警，预知风险。

MSE ZooKeepr 提供风险管理的能力，风险管理会定期扫描集群风险，通知用户，zxid 溢出就是集群的风险之一，当 zxid 接近溢出值之前，通过风险管理对风险的扫描，就可以看到集群zxid溢出的风险，提前做好规避。

风险管理会每天扫描集群的各项风险，也可以通过手动触发 一键健康检查进行集群风险诊断。

同时通过 MSE ZooKeeper 的集群选主时间告警，可以检测集群的选主时间，避免因为集群选主时间过长导致业务损失。通过告警管理中创建 MSE 告警规则进行集群选主时间的告警设置。

原因分析

什么是zxid，它是怎么产生的？

首先我们了解一下什么是 zxid，它是怎么产生的：zxid 是 ZooKeeper 中一个事务的全局唯一 id，通过 zxid 描述各个事务之间的全序关系。客户端对 ZooKeeper 内部数据的变更都是通过事务在 ZooKeeper 集群内的传播和处理完成的，因此 zxid 就是客户端对数据进行一次变更所产生的事务在全局事务中的一个唯一 id，这个 id 描述了本次变更的事务在全局事务中的位置，并且不会有两个不同的事务拥有相同的 zxid（全序关系）。

zxid 是一个 64bits 的数，有两个部分组成：当前选举周期（epoch，占用高32bits）以及计数部分（counter，占用低32bits），epoch 表示 leader 关系的变化，每当新的集群产生新的leader，都会产生一个新的 epoch表示当前 leader 的选举周期，ZooKeeper 集群选主成功之后保证只会有一个Leader，并且此 Leader 的 epoch 是以前没有使用过的，这就保证了只会有一个 leader 使用本次选举过程中产生的 epoch， 在此基础上，每当客户端对数据进行变更的时候，leader 对产生的事务在当前 counter 的值加一产生新的事务的 zxid，并使用此 zxid 将此事务在集群中进行同步，这样就保证了事务的全序关系。

为什么 zxid 溢出需要重新选主

通过研究 zxid 的组成，可以发现，当单个 epoch 中处理的事务过多，以至于当前epoch 对应的 counter 数值超过了 32bits 计数的最大值，如果继续计数 epoch 就会 +1 ， 如果在未来，进行了一次选举，其他的 Server 当选了 leader，但是他产生的新 epoch 可能就会和现在 zxid 中的 epoch 重合，导致不同的事务会有相同的 zxid，破坏了事务之间的全序关系，可能导致脏数据的产生。因此 ZooKeeper 在低 32 位达到最大计数值的时候，就会主动产生一次选主，避免以上问题。

ZooKeeper 集群选主会产生什么影响

一般情况下使用 ZooKeeper 作为注册配置中心，集群选主对于客户端来说是无感知的，集群选主之后客户端会主动重连恢复，但是对于依赖于 ZooKeeper Disconnected 事件的应用，可能会受到影响，在集群选主的时候，Server会向客户端返回 Disconnected 事件，例如 Curator recipes 中 LeaderLatch 类型，在 ZooKeeper 集群选主的时候，LeaderLatch 会重新分配 Leader。

往期内容回顾

• ZooKeeper 避坑实践：如何调优 jute.maxbuffer
• ZooKeeper 避坑实践：SnapCount 设置不合理导致磁盘爆满，服务不可用

点击此处来查看微服务引擎产品