ZooKeeper 技术内幕:数据的存储(持久化机制)

1. 数据分类

整体分为 3 类:

  • 内存数据
  • 磁盘数据
    • 快照
    • 事务日志

下面是 ZooKeeper 启动过程中,3 类数据之间的关系:

image

1.1. 内存数据

关键点:

  • ZK 的数据模型:
    • 树中单个节点包含的内容:
      • 节点数据
      • 节点 ACL 信息
      • 节点的路径
  • 具体实现:DataTree 和 DataNode,见下图

[图片上传中...(image-760fb9-1571726111369-5)]

抛出 2 个问题:

  1. DataTree 中 nodes 是 Map,表示所有的 ZK 节点,那其内部 key 是什么?
    • Re:ZNode 的唯一标识 path 作为 key
  2. ephemerals 是Map,用于存储临时节点,那其内部 key 是什么?value 又是什么?
    • Re:临时节点是跟 Session 绑定的,sessionId 作为 key

懂的,都是看过源码的。

1.2. 快照数据

快照数据生成的基本过程:

[图片上传失败...(image-f77edc-1571726111369)]

关键点:

  1. 异步:异步线程生成快照文件
  2. Fuzzy 快照:
    • 快照文件生成过程中,仍然有新的事务提交,
    • 因此,快照文件不是精确到某一时刻的快照文件,而是模糊的
    • 这就要求事务操作幂等的,否则产生不一致。

疑问:是否每次生成快照文件,都会认为「事务日志已经写满」,并切换一次事务日志文件?所以,切换事务日志文件的时机,实际是生成快照文件的时机。

1.3. 事务日志

关键点:

  1. 事务日志频繁 flush 到磁盘,消耗大量磁盘 IO
  2. 磁盘空间预分配:事务日志剩余空间 < 4KB 时,将文件大小增加 64 MB
  3. 磁盘预分配的目标:减少磁盘 seek 次数
  4. 建议:事务日志,采用独立磁盘单独存放

疑问:事务日志每次增长 64MB,什么时候切换新的事务日志?

[图片上传中...(image-625ca2-1571726111369-3)]

事务序列化:本质是生成一个字节数组

  1. 包含:事务头、事务体的序列化
  2. 事务体:会话创建事务、节点创建事务、节点删除事务、节点数据更新事务

日志截断:

  1. 现象:Learner 的机器上记录的 zxid 比 Leader 机器上的 zxid 大,这是非法状态;
  2. 原则:只要集群中存在 Leader,所有机器都必须与 Leader 的数据保持同步
  3. 处理细节:遇到非法状态,Leader 发送 TRUNC 命令给特定机器,要求进行日志截断,Learner 机器收到命令,会删除非法的事务日志

2. 数据相关过程

2.1. 初始化

ZK 服务器启动时,首先会进行数据初始化,将磁盘中数据,加载到内存中,恢复现场。

image

疑问:初始化最后,为什么要校验 Epoch?如何判断校验成功失败?如果失败,如何处理?

2.2. 数据同步

ZK 集群服务器启动之后,会进行 2 个动作:

  1. 选举 Leader:分配角色
  2. Learner 向 Leader 服务器注册:数据同步

数据同步,本质:将没有在 Learner 上执行的事务,同步给 Learner。

[图片上传中...(image-e771ab-1571726111369-1)]

关键点:

  1. 集群启动后,什么时候能够对外提供服务?需要等所有 Learner 都完成数据同步吗?
    • Re:过半策略:只需要半数 Learner 完成数据同步,Learder 向所有已经完成数据同步的 Learner 发送 UPTODATE 命令,表示集群具备了对外服务能力

几种同步:

  1. 增量同步
  2. 回滚
  3. 回滚,增量同步
  4. 全量同步

下面一张图,能够清晰描述发生上述同步的时机:

[图片上传中...(image-974f89-1571726111368-0)]

关键点:Learner 上的 zxid 与 Leader Proposals 中 min 和 max 的关系

3. 总结

ZK 的数据与存储中,有几个特别关注点:

  1. 内存数据磁盘数据间的关系:
    • 内存数据,是真正提供服务的数据
    • 磁盘数据,作用:
      • 恢复内存数据,恢复现场
      • 数据同步:集群内,不同节点间的数据同步(另,内存中的提议缓存队列 proposals)
      • 磁盘数据,为什么同时包含:快照、事务日志?出于数据粒度的考虑
        • 如果只包含快照,那恢复现场的时候,会有数据丢失,因为生成快照的时间间隔太大,即,快照的粒度太粗了
        • 事务日志,针对每条提交的事务都会 flush 到磁盘,因此粒度很细,恢复现场时,能够恢复到事务粒度上
  2. 快照生成的时机:基于阈值,引入随机因素
    • 解决的关键问题:避免所有节点同时 dump snapshot,因为 dump snapshot 耗费大量的 磁盘 IO、CPU,所有节点同时 dump 会严重影响集群的对外服务能力
    • countLog > snapCount/2 + randRoll,其中:
      • countLog 为累计执行事务个数
      • snapCount 为配置的阈值
      • randRoll 为随机因素(取值:0~snapCount/2)
  3. ZK 的 快照文件是 Fuzzy 快照,不是精确到某一时刻的快照,而是某一时间段内的快照
    • ZK 使用「异步线程」生成快照:
      • 线程之间共享内存空间,导致 Fuzzy 快照
      • 这就要求 ZK 的所有事务操作是幂等的,否则产生数据不一致的问题
      • 实际上 ZK 的所有操作都是幂等的
    • 类比:Redis 中使用「异步进程」生成快照 RDB(Redis Dump Binary)
      • RDB 文件是精确的快照,原因:进程之间内存空间隔离
      • 系统内核使用「写时复制」(Copy-On-Write)技术,节省大量内存空间

参考资料

  • 从Paxos到Zookeeper分布式一致性原理与实践 第7章 7.9
  • ZooKeeper-Distributed Process Coordination 第2章 2.1.3 & 第4章

http://ningg.top/zookeeper-lesson-9-zookeeper-data-and-storage/

你可能感兴趣的:(ZooKeeper 技术内幕:数据的存储(持久化机制))