MSE ZooKeeper 数据导入导出功能上线

作者：草谷

背景

MSE 提供了托管版的 ZooKeeper，拥有比自建开源 ZooKeeper 稳定性更高的SLA，同时管控面提供了丰富的服务自治功能。赶在2022年的岁末，MSE ZooKeeper 上线了一个非常实用的功能-数据导入导出功能，彻底解决了困恼用户长期以来无法自助处理数据的问题。通过阅读本文，你可以快速获得以下知识点和能力：

ZooKeeper 的持久化文件原理
什么场景下会使用到导入导出功能
如何在 MSE 上面使用导入导出功能

存储原理

此次上线的导出功能支持的数据类型包含快照文件snap和事物日志，在介绍功能之前，我们看下 ZooKeeper 的这2个数据文件是用来做什么的。

在 ZooKeeper 中，主要会产生2种和数据相关的持久化文件，一个是内存的数据快照 Snapshot 文件，另外一个是事务日志 log 文件；它们分别是什么作用，有什么区别呢？

下面2段代码是 Snap 快照的写入内容和产生的时机：

public void save(
    DataTree dataTree,
    ConcurrentHashMap<Long, Integer> sessionsWithTimeouts,
    boolean syncSnap) throws IOException {
    long lastZxid = dataTree.lastProcessedZxid;
    File snapshotFile = new File(snapDir, Util.makeSnapshotName(lastZxid));
    try {
        snapLog.serialize(dataTree, sessionsWithTimeouts, snapshotFile, syncSnap);
    } catch (IOException e) {
     //
    }
}

private boolean shouldSnapshot() {
    int logCount = zks.getZKDatabase().getTxnCount();
    long logSize = zks.getZKDatabase().getTxnSize();
    return (logCount > (snapCount / 2 + randRoll))
           || (snapSizeInBytes > 0 && logSize > (snapSizeInBytes / 2 + randSize));
}

可以看到，Snapshot 写入的是一个 DataTree 的数据结构，里面存储的是 ZooKeeper 的全量内存数据，而生成 Snapshot 的条件，主要涉及到 snapCount，snapCount 是一个可配置的参数，默认是10W，也就是 Snapshot 是 Zookeeper 的内存快照，是一份全量数据，而这份全量数据，也并非实时写入到磁盘中的，需要达到一定的条件才会写入。

再看 ZooKeeper 的事务日志，针对客户端的每一次事务操作，Zookeeper 都会将他们记录到事务日志中，同时也会将数据变更应用到内存数据库中。刚才说到 Snapshot 的生成并非实时的，在上一次内存快照生成后，到下一份生成之前，就会有一部分数据没有写入到 Snapshot 中，那么这部分增量的数据，我们可以从事务日志中找到。

总结一下，简单来说，Snapshot 是存储的全量数据，事务日志 log 文件是记录着完整的每次事务操作，所以如果要完整的恢复一个 ZooKeeper 集群的数据，需要同时具备这2个文件。

使用场景

MSE 数据导入导出功能主要来自于客户的需求反馈，主要有如下三种使用场景：

数据的备份

如果需要对集群某个时刻的数据进行备份，用于后续恢复或者容灾使用，可以使用 MSE 的数据导出功能，将集群的数据导出成文件进行存储，如果集群出现了数据不符合预期的情况下，可以通过导入的功能，将集群数据恢复到备份时的状态

集群的迁移

需要迁移到新的 ZooKeeper 集群，又依赖到原 ZooKeeper 集群的数据时，可以通过 MSE 的数据导出功能，将数据导出，然后再放到新集群中，重新初始化，这样就相当于做了一次全量的数据迁移，这种迁移是需要停机的，但胜在简单易操作

分析客户端业务

MSE 导出的 Snapshot 文件和 log 文件，可以通过 ZooKeeper 自带的解析工具，解析成明文，里面包含的信息非常丰富，每条数据的大小，访问频率等，通过这些，可以查到一部分客户端是否错用 Zookeeper，能具体到路径，帮助揪出有问题的客户端。例如我们遇到过有用户客户端错用导致一个 Session 写入了大量的数据，最后通过分析事务文件，找到了具体的客户端IP和应用名，解除了风险。