（十五）Zookeeper原理源码分析之数据日志文件归档

1. 日志文件概述

1.1 作用说明

  ZK框架不依赖于我们所理解的常规数据库&＃xff0c;但服务器运行时需要记录处理过的客户端请求&＃xff0c;ZK的处理方式则是将请求信息序列化到文件中。ZK将日志请求分为两种&＃xff1a;

• 事务日志&＃xff1a;用于记录接收过的每个客户端请求&＃xff0c;里面会保存接收时间、cxid值、zxid值、操作类型、操作路径和请求数据&＃xff1b;事务日志文件的核心作用有两个&＃xff1a;
  1. 根据日志文件可快速查阅在什么时间点服务端处理过什么操作&＃xff0c;方便排查问题&＃xff1b;
  2. 在ZK服务器启动时&＃xff0c;会将事务日志中zxid大于最新快照的zxid的请求再处理一遍&＃xff0c;防止请求遗漏。
• 快照日志&＃xff1a;在ZK服务器运行了一定的时间后或处理了一定的请求后&＃xff0c;将ZK服务器当前状态记录并保存到文件中&＃xff0c;形成快照文件&＃xff0c;因此快照文件的数据就是某一时刻ZK服务器的数据记录&＃xff1b;其作用在于ZK服务器重启时&＃xff0c;可以读取最新的快照文件&＃xff0c;恢复到上次停止时的状态。

  上面一些名词的简单说明&＃xff1a;

• cxid值&＃xff1a;客户端每次请求cxid都会&＃43;1&＃xff0c;初始值为1&＃xff0c;在客户端的属性名为xid&＃xff1b;
• zxid值&＃xff1a;事务唯一ID&＃xff0c;ZK服务端的全局变量&＃xff0c;能够保证请求事务的唯一性。

1.2 日志文件格式

  如果要看事务日志文件的内容&＃xff0c;ZK官方提供了对应的可执行Main函数类LogFormatter和SnapshotFormatter&＃xff0c;其中LogFormatter针对的是ZK的事务日志文件&＃xff0c;SnapshotFormatter则是针对ZK的快照日志文件。

  若想要直接使用Idea编译器来查看日志文件&＃xff0c;以事务日志文件为例&＃xff0c;只需要进入到类LogFormatter中&＃xff0c;点击执行按钮&＃xff0c;在弹窗的Program arguments一栏中填入需要查看的事务日志文件的路径即可&＃xff0c;如下图&＃xff1a;

  一般而言直接执行会因为事务日志的内容太多&＃xff0c;而导致Idea的控制台无法全部展示&＃xff0c;此时只需要再配置控制台的输出重定向就可以了&＃xff0c;如下图&＃xff1a;

  ZK的事务日志文件需要从ZK的服务器日志目录拉取&＃xff0c;经过上面两种配置就可以顺利把ZK的事务日志文件读取并输出到对应的本地文件中了。

  如果要解析快照日志文件&＃xff0c;只需要进入SnapshotFormatter再重复上述两个步骤即可&＃xff0c;但最好重定向的文件名不要一致。

1.2.1 事务日志文件解析

  先从事务日志文件的命名格式开始说起&＃xff0c;事务日志的文件名是 log.&＃43;事务日志文件中第一个请求事务的zxid&＃xff0c;解析重定向到本地文件中格式如下&＃xff1a;

{time}" session 0x"{clientId}" cxid 0x"{cxid}" zxid 0x"{zxid}" "{type}" "{txnContent}


  以下为真实数据内容&＃xff1a;

ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
22-1-21 下午09时57分00秒 session 0x37c82be90ee01c9 cxid 0x2642ac zxid 0x22000595ba create &＃39;/XXXX/XXXX/X/XX/X,,v{s{31,s{&＃39;world,&＃39;anyone}}},T,43304022-1-21 下午09时57分00秒 session 0x37c82be90ee01c9 cxid 0x2642b8 zxid 0x22000595bc delete &＃39;/XXXX/XXXX/X/XX/X22-1-21 下午09时58分44秒 session 0x17dbd96b867001a cxid 0x263b2 zxid 0x22000595ce setData &＃39;/XX/XXXXX/XXX/X,XXXXXXX,52086


  第一行用来标识本ZK事务日志文件所支持的jar包版本&＃xff0c;避免不同事务格式日志文件混用报错。从日志文件内容可以得到session的clientId、cxid、zxid和操作类型&＃xff0c;都是16进制&＃xff0c;具体的txnContent内容每个请求都各不相同。根据本日志文件可以得到具体时间点的具体操作及内容&＃xff0c;从而实现生产问题排查。

  在ZK重启时&＃xff0c;会根据事务日志文件名的zxid判断具体应该读取哪个事务日志文件&＃xff0c;读取出来后再使用zxid去过滤已经处理过的请求&＃xff0c;从而实现恢复到ZK停止前的状态。

1.2.2 快照日志文件解析

  快照日志文件名的格式为&＃xff1a;snapshot.&＃43;服务器最新的zxid&＃xff0c;事务日志的格式如下&＃xff1a;

ZNode Details (count&＃61;{nodeCount}):
----
/cZxid &＃61; {cZxid}ctime &＃61; {ctime}mZxid &＃61; {mZxid}mtime &＃61; {mtime}pZxid &＃61; {pZxid}cversion &＃61; {cversion}dataVersion &＃61; {dataVersion}aclVersion &＃61; {aclVersion}ephemeralOwner &＃61; {ephemeralOwner}dataLength &＃61; {dataLength}
----
/
省略N个被序列化的快照节点信息
----
Session Details (sid, timeout, ephemeralCount):
{sessionId}, {timeout}, {ephemeralCount}
以下忽略N个session的超时信息


  快照日志的信息看起来信息很多&＃xff0c;但实际上基本都是DataNode中的StatPersisted stat成员属性&＃xff0c;接下来挨个分析一下各个属性的代表含义&＃xff1a;

1. nodeCount&＃xff1a;快照文件中所包含的节点数量&＃xff1b;
2. cZxid&＃xff1a;创建该节点请求的zxid&＃xff1b;
3. ctime&＃xff1a;创建该节点的请求时间&＃xff1b;
4. mZxid&＃xff1a;最后修改节点的请求zxid&＃xff1b;
5. mtime&＃xff1a;最后修改节点的请求时间&＃xff1b;
6. pZxid&＃xff1a;增加删除节点时&＃xff0c;操作父节点与当前节点的请求zxid值&＃xff0c;因此如果有父子关系&＃xff0c;则节点的pZxid会一致&＃xff0c;且子节点的cZxid会与pZxid一致&＃xff1b;
7. cversion&＃xff1a;节点创建版本值&＃xff0c;取值为父节点的cversion&＃43;1&＃xff0c;因此子节点的值一定是比父节点要大的&＃xff1b;
8. dataVersion&＃xff1a;数据节点版本&＃xff0c;主要由客户端控制&＃xff1b;
9. aclVersion&＃xff1a;如果为新增节点&＃xff0c;值为0&＃xff0c;如果为客户端发送的setAcl请求&＃xff0c;则取决于客户端传值&＃xff1b;
10. ephemeralOwner&＃xff1a;是否是临时节点&＃xff0c; 如果不是则值为0&＃xff0c;是则为某个客户端的sessionId值&＃xff1b;
11. dataLength&＃xff1a;节点成员属性byte[] data数组的长度&＃xff1b;
12. sessionId&＃xff1a;与客户端一一对应的唯一值&＃xff0c;初始值为0&＃xff0c;每当一个新的客户端连接进来&＃xff0c;则&＃43;1&＃xff0c;在集群中能够代表具体哪台客户端机器&＃xff1b;
13. timeout&＃xff1a;客户端的失效时间&＃xff1b;
14. ephemeralCount&＃xff1a;客户端下有多少个临时节点的数量值&＃xff1b;

  一共14个不同的参数&＃xff0c;有几个参数的值内容值得推敲&＃xff0c;实际快照日志文件内容如下&＃xff1a;

ZNode Details (count&＃61;{nodeCount}):
----
/kafka1/brokers/topics/X.XX.XXX/partitions/11cZxid &＃61; 0x00002200053b0fctime &＃61; Thu Jan 20 10:16:29 CST 2022mZxid &＃61; 0x00002200053b0fmtime &＃61; Thu Jan 20 10:16:29 CST 2022pZxid &＃61; 0x00002200053b2ccversion &＃61; 1dataVersion &＃61; 0aclVersion &＃61; 0ephemeralOwner &＃61; 0x00000000000000no data
----
/kafka1/brokers/topics/X.XX.XXX/partitions/11/statecZxid &＃61; 0x00002200053b2cctime &＃61; Thu Jan 20 10:16:29 CST 2022mZxid &＃61; 0x00002200053b2cmtime &＃61; Thu Jan 20 10:16:29 CST 2022pZxid &＃61; 0x00002200053b2ccversion &＃61; 0dataVersion &＃61; 0aclVersion &＃61; 0ephemeralOwner &＃61; 0x00000000000000dataLength &＃61; 72
----
Session Details (sid, timeout, ephemeralCount):
0x17c82be90e20023, 10000, 1
0x17c82be90e20024, 40000, 25


  从上面的简单例子便可以看出&＃xff0c;可以通过cZxid和pZxid确认第一个节点是第二个节点的父节点&＃xff0c;因为第一个节点cZxid和pZxid不一致&＃xff0c;但是第二个节点两个属性的值是一致的。

2. 日志文件序列化

2.1 日志路径配置

  如果要说日志文件的序列化&＃xff0c;那首先是需要搞定出文件要被序列化在哪里并从哪里读取反序列化。ZK启动前可在properties配置文件中配置dataDir和dataLogDir属性来确定事务、快照日志文件路径。除了配置properties文件中的路径属性&＃xff0c;也可以以参数传入&＃xff0c;参数传入则只能有三个参数&＃xff0c;第二个参数为路径属性&＃xff0c;且dataDir&＃61;dataLogDir。

  其中会先加载dataDir路径文件&＃xff0c;再去加载dataLogDir路径文件&＃xff0c;需要注意&＃xff1a;dataDir&＃61;snapLog&＃xff0c;dataLogDir&＃61;txnLog。所以实际上是先加载快照日志文件&＃xff0c;再去加载事务日志文件&＃xff0c;先从快照日志文件获取ZK停机前最新的zxid&＃xff08;如果有的话&＃xff09;&＃xff0c;再使用获取到的zxid去过滤事务日志文件中已经被处理过的请求&＃xff0c;防止重复消费。

2.2 序列化时机

  前面确定了ZK日志文件的存储位置&＃xff0c;那么问题来了&＃xff0c;ZK是如何判断当前应该进行写文件及归档呢&＃xff1f;总不可能让请求信息一直无限制增加吧&＃xff1f;所以肯定ZK会有个阈值&＃xff0c;超过这个阈值后就进行一次归档&＃xff0c;且最好要是可配的。

  ZK也确实是这样做的&＃xff0c;ZK服务器可配置zookeeper.snapCount属性&＃xff0c;用来控制快照文件的数量&＃xff0c;默认值大小为100000。服务器设置归档的范围是[0,snapCount/2] &＃43; snapCount/2&＃xff0c;如果要保证可以有数字随机&＃xff0c;其值最低只能为2&＃xff0c;如果是1&＃xff0c;随机的范围就只有0了&＃xff0c;不符合随机要求。

  只要看过前面ZK源码的小伙伴&＃xff0c;就会知道ZK服务器在处理客户端的请求时&＃xff0c;一定会经过SyncRequestProcessor处理器&＃xff0c;这个处理器就是用来统计已处理的请求数量并判断是否超过阈值需要进行归档。判断流程图如下&＃xff1a;

  流程中有以下几点需要注意&＃xff1a;

• randRoll在每个归档周期内都会重新设置随机值&＃xff0c;随机范围[0,snapCount/2]&＃xff0c;其目的在于动态伸缩ZK的日志归档大小。这样做的原因在于ZK会向集群内的所有机器同步请求&＃xff0c;如果归档大小都是一样的&＃xff0c;一段时间内所有的机器都在进行归档&＃xff0c;占用IO&＃xff0c;从导致集群在这一段时间的性能降低&＃xff1b;如果归档时间不一样&＃xff0c;就可以保证集群总体而言性能不会由于IO使用而降低太多&＃xff1b;
• 当SyncRequestProcessor请求接收到requestOfDeath固定请求&＃xff0c;则说明ZK由于某种原因需要关闭&＃xff0c;此时将会退出死循环&＃xff0c;否则将一直运行下去&＃xff0c;即使轮询不到请求&＃xff1b;
• 要添加到事务日志文件中&＃xff0c;TxnHeader必须不为空&＃xff0c;一般而言除了ping操作&＃xff0c;其它的正常操作诸如create、get、set、delete等&＃xff0c;都是可以成功添加到事务日志中的&＃xff1b;
• randRoll随机范围是[0,snapCount/2]&＃xff0c;事务日志的阈值范围是[snapCount/2,snapCount]&＃xff0c;每当有一个事务请求添加到事务日志中&＃xff0c;logCount将会&＃43;1&＃xff1b;
• 在超过事务日志阈值前&＃xff0c;事务请求都是被保存在BufferedOutputStream缓存中的&＃xff0c;只要超过阈值后&＃xff0c;事务日志才会写到文件中&＃xff0c;且快照日志进行归档&＃xff0c;logCount清零&＃xff1b;
• 一台机器同时只会操作一个快照日志文件&＃xff0c;如果上一次的文件还没写入完成&＃xff0c;则下次快照归档会跳过&＃xff1b;

  除了上面几点外&＃xff0c;还需要特别注意toFlush集合&＃xff0c;该集合需要注意两点&＃xff1a;

1. 事务请求添加到toFlush集合的情况&＃xff1a;
   1. 当事务请求添加到事务文件成功时&＃xff1b;
   2. 添加到事务文件失败且toFlush集合不为空&＃xff1b;
2. 清空toFlush集合事务请求&＃xff0c;并将里面的事务请求交给下个RequestProcessor处理的情况&＃xff1a;
   1. toFlush集合不为空&＃xff0c;且无新的请求进入SyncRequestProcessor处理器时&＃xff1b;
   2. 新的toFlush请求进入&＃xff0c;添加到事务日志文件失败且toFlush集合为空&＃xff0c;直接交给下个RequestProcessor处理&＃xff1b;
   3. 当事务请求添加到toFlush集合成功&＃xff0c;且集合数量大于1000时&＃xff0c;主动清空集合&＃xff0c;并将里面的请求全部交给下个RequestProcessor处理。

  对于toFlush集合的操作&＃xff0c;结合流程图应该大致能搞懂里面的逻辑&＃xff0c;如果觉得很绕&＃xff0c;结合源码再来看这些注意点就能够很轻松的搞懂了。

2.3 日志文件的管理

  进行归档时会实例化一个ZooKeeperThread类型的线程对象&＃xff0c;执行takeSnapshot()方法生成快照日志文件&＃xff0c;而事务日志文件只需要将BufferedOutputStream缓存中的刷到文件中即可。

  ZK往复执行上面的归档流程&＃xff0c;如果没有对日志文件进行管理的机制&＃xff0c;那就肯定是需要人工定时维护的&＃xff0c;从3.4.X版本开始&＃xff0c;支持配置两个属性来定时清理日志文件&＃xff0c;如下&＃xff1a;

1. 可在properties属性文件中配置autopurge.purgeInterval属性&＃xff0c;用来设置间隔多久进行清理&＃xff0c;单位小时h&＃xff0c;默认值0&＃xff0c;即不清理&＃xff0c;所以如果要配最小清理间隔为1h&＃xff1b;
2. 配置autopurge.snapRetainCount属性用来控制需要保留的快照文件数量snapRetainCount属性&＃xff0c;默认值为3&＃xff0c;最小值可配为3&＃xff0c;配了之后将会保留最新的snapRetainCount个快照日志文件&＃xff1b;

  注&＃xff1a;上述的autopurge.snapRetainCount属性只控制快照日志文件&＃xff0c;事务请求文件会清理比快照文件zxid最小还要小的。以下面为例&＃xff1a;

假设现在快照文件共有6个&＃xff0c;事务日志文件共有6个&＃xff1a;

  假设autopurge.snapRetainCount属性为默认的3&＃xff0c;清理后的日志文件为&＃xff1a;

  因为快照日志文件最小的zxid为7&＃xff0c;因此事务日志文件名的zxid小于7的都要删除。