共计 4106 个字符，预计需要花费 11 分钟才能阅读完成。
作者：子葵
背景
在 ZooKeeper 的日常应用过程中，一个令人头疼的问题就是节点的磁盘容量问题，如果因为过大的 TPS 或者不适当的清理策略会导致集群中数据文件，日志文件的沉积，最终导致磁盘爆满，Server 宕机。近期就在线上发现某用户的一个集群在一个时间段内的 TPS 暴增。
导致磁盘中 snapshot 和 transaction log 文件十分多。
最终导致磁盘被写满，节点服务不可用。
本篇通过深刻解读 ZooKeeper 数据文件生成机制，以及 ZooKeeper 中和数据文件生成相干的参数，探索一下 解决 ZooKeeper 磁盘问题的最佳实际。
剖析
ZooKeeper 中生成的数据文件有哪些？
首先咱们须要探索一下 ZooKeeper 对数据进行长久化的基本原理，ZooKeeper 为了保障所有的数据变更不失落，采纳状态机来进行数据的记录和复原，简略来讲，ZooKeeper 中有一个大 Map 存储所有 Znode，key 就是 Znode 的 Path，value 就是 Znode 中的数据，acl，状态等信息，ZooKeeper 通过在某一时间点对内存中的大 Map 进行序列化失去这一时间点内存中数据的一份快照，同时通过另一个文件，存储在此工夫节点之后对这份快照中数据状态的批改操作。
当 ZooKeeper 节点重启的时候，会通过现有的 snapshot 和 transaction log 进行数据恢复。
采纳这种做法可能很好的保障内存中已变更的数据不会失落，同时写性能不会有太多损失，在遇到节点宕机之后，可能残缺的复原数据。
从此看来，ZooKeeper 产生的数据文件次要有两类：内存中数据的快照文件，以及存储变更的事务日志文件，这两类文件别离通过配置文件中的 dataDir 和 dataLogDir 进行指定，这也是 ZooKeeper 中占用磁盘空间比拟大的两类文件。
当 zk 中数据存储过多或者数据变更十分频繁的状况下，将内存中的存储的 snapshot 序列化到文件中，以及数据变更产生的事务日志文件就会很多很大，如果没有配置适合数据清理策略和参数，磁盘问题将会导致集群节点宕机，甚至服务不可用。
public class ZooKeeperServer implements SessionExpirer, ServerStats.Provider {
...
public void takeSnapshot(boolean syncSnap) {long start = Time.currentElapsedTime();
try {txnLogFactory.save(zkDb.getDataTree(), zkDb.getSessionWithTimeOuts(), syncSnap);
} catch (IOException e) {LOG.error("Severe unrecoverable error, exiting", e);
// This is a severe error that we cannot recover from,
// so we need to exit
ServiceUtils.requestSystemExit(ExitCode.TXNLOG_ERROR_TAKING_SNAPSHOT.getValue());
}
...
}
...
}当 Server 尝试将内存中的数据写入磁盘的时候，就会产生异样，Server 过程会间接退出。
对于这些问题，ZooKeeper 官网提供一些参数，通过正当的配置参数可能无效的减缓磁盘压力，接下来深刻探索一下相干参数。
- autopu rge.snapRetainCount : (No Java system property) New in 3.4.0
- autopurge.purgeInterval : (No Java system pro perty) New in 3.4.0
首先 ZooKeeper 官网是反对定时清理数据文件的能力的，通过 autopurge.snapRetainCount 和 autopurge.purgeInterval 指定清理的距离和清理时须要保留的数据文件的个数，这里须要留神的是，ZooKeeper 中开启此能力须要将 autopurge.purgeInterval 设置为一个大于 0 的值，此值代表清理工作运行的距离（单位是小时）。个别状况下，配置这两个参数开启定时清理能力之后可能很大水平加重磁盘的容量压力。然而定时清理工作的最小距离是 1 小时，这在一些非凡场景下无奈防止磁盘爆满的问题。
当在两次磁盘的清理距离中，有大量的数据变更申请时，会产生大量的 transaction log 文件和 snapshot 文件，因为没有达到清理的事件间隔，数据累计最终在下一次磁盘清理之前把磁盘写满。为了更好了了解其余参数，咱们先探索一下 ZooKeeper 会在什么时候产生快照文件和事务日志文件。
ZooKeeper 在什么工夫生成这些数据文件
通过在代码中办法援用（ZooKeeperServer.takeSnapshot），发现在以下状况下会触发新的快照文件的生成
- 节点启动，加载完数据文件之后
- 集群中产生新 leader
- SyncRequestProcessor 中达到肯定条件（shouldSnapshot 办法指定）
前两种状况都是非高频的，咱们看一下第三种状况，在 SyncRequestProcessor 的 run 办法中调用了 takeSnapshot 办法，在此之前调用了 shouldSnapshot 进行了判断：
private boolean shouldSnapshot() {int logCount = zks.getZKDatabase().getTxnCount();
long logSize = zks.getZKDatabase().getTxnSize();
return (logCount > (snapCount / 2 + randRoll))
|| (snapSizeInBytes > 0 && logSize > (snapSizeInBytes / 2 + randSize));
}其中 logCount 的值是以后事务日志文件的大小以及事务日志的数量，snapCount，snapSizeInBytes 是通过 Java SystemProperty 配置的值，randRoll 是一个随机数（0 < randRoll < snapCount / 2）,randSize 也是一个随机数（0 < randSize < snapSizeInBytes / 2），因而这个判断条件的逻辑能够总结为下：
当以后事务日志文件中的事务数量大于运行时产生的和 snapCount 相干的一个随机值（snapCount/2 < value < snapCount）或者以后的事务日志文件的大小大于一个运行是产生的和 snapSizeInBytes 相干的随机值（snapSizeInBytes/2 < value < snapSizeInBytes）就会进行一次 snapshot 的文件写入，并且能够从代码中看到，写入 snapshot 会将当初的事务日志文件刷入磁盘，并新建一个事务日志文件。
public void run() {if (shouldSnapshot()) {resetSnapshotStats();
// 滚动事务日志文件
zks.getZKDatabase().rollLog();
// take a snapshot
if (!snapThreadMutex.tryAcquire()) {LOG.warn("Too busy to snap, skipping");
} else {new ZooKeeperThread("Snapshot Thread") {public void run() {
try {zks.takeSnapshot();
} catch (Exception e) {LOG.warn("Unexpected exception", e);
} finally {snapThreadMutex.release();
}
}
}.start();}
}
}snapCount，snapSizeInBytes 这两个变量能够通过 ZooKeeper 的配置文件中指定。
- snapCount : (Java system property: zookeeper.snapCount)
- snapSizeLimitInKb : (Java system property: zookeeper.snapSizeLimitInKb)
由此可知，能够通过在配置文件中配置 snapCount 和 snapSizeLimitInKb 来管制 snapshot 文件产生的频率。
倡议
通过以上剖析可知，能够通过 4 个参数对 ZooKeeper 的数据文件生成和清理进行配置。
- autopurge.snapRetainCount : (No Java system property) New in 3.4.0
- autopurge.purgeInterval : (No Java system property) New in 3.4.0
- snapCount : (Java system property: zookeeper.snapCount)
- snapSizeLimitInKb : (Java system property: zookeeper.snapSizeLimitInKb)
前两个配置项指定 ZooKeeper 的定时清理策略，后两个参数配置 ZooKeeper 生成快照文件的频率。
依据后面剖析，能够指通过将 snapCount 和 snapSizeLimitInKb 调整大能够减小 snapshot 的生成频率，然而如果设置的过大，会导致在节点重启时，加载数据迟缓，缩短服务的复原工夫，增大业务危险。
autopurge.purgeInterval 最小只能指定为 1，这将清理距离硬限度到 1 小时，针对高频写入情景无奈升高危险。
MSE ZooKeeper 针对以上剖析的 ZooKeeper 的磁盘问题，设置了适合的参数，并且用户能够不便更改相干参数实现业务场景适配，并且 MSE ZooKeeper 在 ZooKeeper 本身的数据清理机制外，提供额定保障伎俩，保障集群免受磁盘问题影响。
经营流动
重磅推出 MSE 专业版，更具性价比，可间接从根底版一键平滑降级到专业版！
点击 此处 ，返回微服务引擎 MSE 官网查看更多～