背景
(资料图)
Cloud Native
ZooKeeper 作为分布式系统的元数据中心，对外服务的数据一致性需要得到很好的保证，但是一些老版本的 ZooKeeper 在一些情况下可能无法保证数据的一致性，导致依赖 ZooKeeper 的系统出现异常。
某用户使用 3.4.6 版本 ZooKeeper 做任务调度，ZooKeeper 实例的 tps 和 qps 都比较高，事务日志产生的速率很快，即使此用户配置了自动清理的参数，但是自动清理的最小间隔还是赶不上数据产生的速度，导致磁盘爆满。
在此用户清理了旧日志之后，重启节点，部分业务机器就报出 NodeExist，NoNode 的异常，并且报错只集中在部分机器，此次异常导致用户任务调度系统出现任务重复调度以及任务丢失问题，产生重大损失。
原因分析
Cloud Native
仔细检查了这些客户端发现这些客户端都连接在同一台 ZooKeeper 节点上，通过 zkCli 手动排查节点上的数据，对比其他未清理磁盘的 ZooKeeper 节点，清理了磁盘的 ZooKeeper 节点中的数据和其他节点具有差异，此时确定此节点由于一些原因出现了数据不一致问题，导致连接到此节点的客户端读到了脏数据。
但是排查日志，没有发现异常日志。由于此节点之前清理过日志，并且重启过，磁盘上的数据被重新加载过，因此怀疑是 ZooKeeper 在启动加载数据的过程中出现了一些异常情况。通过分析 ZooKeeper 启动中加载数据的代码，继续排查具体原因。
public long restore(DataTree dt, Map此处是 ZooKeeper 加载磁盘数据的代码，此方法的主要作用是，首先将磁盘中的 snapshot 文件加载进内存，初始化 ZooKeeper 内存中的数据结构，之后将加载事务日志应用日志中对数据的修改，最终还原磁盘中数据的状态。
但是在 3.4.6 版本的代码中 snapLog.deserialize(dt, sessions);这行加载 snapshot 文件的代码有一个返回值，此处没有进行返回值校验，导致在 ZooKeeper 本身找不到有效的 snapshot 文件的情况下还是会继续加载事务日志，从而导致 ZooKeeper 在空数据的状态下直接应用事务日志，最终导致此节点的数据和其他节点的数据不一致。
此问题已经在 ZooKeeper 社区有对应的issue，在加载 snapshot 的文件列表为空的情况下，此问题已经得到了修复，但是由于磁盘爆满导致的 snapshot 文件不完整的其他的一些特殊情况下，此问题依然存在。解决此问题还需要从磁盘使用的角度解决。
issue：
https://issues.apache.org/jira/browse/ZOOKEEPER-2325
解决方案
Cloud Native
为了避免 ZooKeeper 节点的磁盘被快速打满，可以增加磁盘的容量，配合 ZooKeeper 本身的清理机制，可以在一定范围内的 tps 下避免磁盘被写满的情景，但是增大磁盘容量会带来显著的使用成本的提高，并且即使磁盘容量提高了，也可能因为 ZooKeeper 本身清理机制不及时清理，导致磁盘被打满，最终需要通过人工的方式进行磁盘清理，运维起来很复杂，耗费人力物力，并且集群稳定性得不到显著提升。
MSE ZooKeeper 提供 ZooKeeper 实例的全托管，MSE ZooKeeper 实例的磁盘使用对用户完全透明，用户无需担心磁盘爆满问题，以及磁盘使用过程中的复杂运维。MSE ZooKeeper 通过定时清理，触发使用阈值清理等手段保证 ZooKeeper 实例在使用过程中磁盘始终处于安全水位，避免由于磁盘问题导致的数据不一致，实例不可用等问题。
MSE ZooKeeper 默认集成 Promethus 监控，提供丰富的指标信息，并且针对写多的场景，MSE ZooKeeper 提供 TopN 大盘，能够快速看到业务热点数据，以及高 tps 的客户端情况，能够通过这些统计数据快速定位业务使用过程中的问题。
快速加K8s学习交流群，与大佬共卷！
扫码加我微信，进群和大佬们零距离
