初稿(背景，调研，架构设计) 2021-03-30 李小翠 增加快照部分 2021-04-13 李小翠、陈威 补充元数据数据结构 2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 指向同一个inode 文件系统快照 方案一：文件/目录级别快照 快照是文件系统或卷的只读副本，快照要求可以即时创建。类似 moosefs，curvefs 可以计划支持目录及文件级别的快照，目录级别和文件级别的快照可以认为就是cp的实现。 对于文件/目录级别的快照： 检查目的节点的父节点中是否有同名文件存在： 存在 若源节点类型为TYPE_DIRECTORY则对源节点目录下的所有子文件进行快照 若源节点类 inode 是否相同，若完全一样则说明目的节点已经是源节点的快照了不需要做任何处理, 否则删除目的节点，再创建新的 dentry 指向源节点的 inode 若源节点类型为TYPE_SYMLINK，重新设置目的节点与源节点保持一致 不存在 创建新的dentry 若源节点type= TYPE_DIRECTORY，递归创建源节点目录下的所有子文件进行快照 若源节点type= TYPE_FILE，则设置len

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 818 7.6.6 TiDB 主从集群数据校验和快照读· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 821 7.6.7 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1205 9.5 将 Grafana 监控数据导出成快照 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1206 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 2347 13.7.9 逻辑导入模式· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 951 9.5 将 Grafana 监控数据导出成快照 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 952 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 2088 13.7.9 逻辑导入模式· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · TiDB Lightning 的逻辑导入模式支持预处理语句和客户端语句缓存 #54850 @dbsid 通过开启配置项 logical-import-prep-stmt，TiDB Lightning 逻辑导入模式中执行的 SQL 语句将通过使用 预处理语句和客户端语句缓存，降低 TiDB SQL 解析和编译的成本，提升 SQL 执行效率，并有更大机会命 中执行计划缓存，提升逻辑导入的速度。 更多信息，请参考用户文档。

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 885 9.5 将 Grafana 监控数据导出成快照 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 886 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 2023 13.7.9 逻辑导入模式· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 更多信息，请参考用户文档。 2.2.1.4 SQL 功能 • TiDB 支持 JSON Schema Validation 函数 #52779 @dveeden 在 v8.2.0 之前，你需要依赖外部工具或自定义验证逻辑进行 JSON 数据验证，开发和维护比较复杂，开发 效率低。从 v8.2.0 版本开始，引入了 JSON_SCHEMA_VALID() 函数。通过在 CHECK 约束中使用 JSON_SCHEMA �→

+ new)，一旦共同一 致已经被提交，系统切换到新的配置(new)。RAFT协议简介 日志压缩 • 日志会不断增长，占用空间 • 采用快照的方式压缩日志 • 在某个时间点，整个系统的状态都以快照的形式写入 到稳定的持久化存储中 • 完成一次快照之后，删除时间点之前的所有日志和快 照。BRAFT简介 • raft协议提出之后，涌现出了非常多的实现，比如etcd，braft，tikv等。 • braft是raft的一个实现，实现了raft的一致性协议和复制状态机，而且提供了一种通用的基础库。基 于braft，可以基于自己的业务逻辑构建自己的分布式系统。 • braft本身不提供server功能，需要业务自己实现状态机。 Node（一个raft实例） int init(const NodeOptions& options); void apply(const Task& task); • chunkserver：采用raft协议3副本的方式保存块 设备上的数据。 • snapshotCloneServer：卷的快照克隆服务，持久 化到S3中。Curve块存储RAFT应用 数据分布 • 每个raft实例用一个copyset管理，copyset是个逻辑 概念。写入chunk的数据，由copyset对应的raft完成 3副本的写入。 • multi-raft：copyset和chunkserver是多对多的关系

Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查基本架构 • 快照克隆服务器 独立于核心服务 储到支持S3接口的 对象存储，不限制数量 异步快照、增量快照 从快照/镜像克隆 ( lazy/非lazy ) 从快照回滚数据组织形式 • 底层 可用性 / 可靠性 扩展性 / 负载均衡 向上提供无差别文件流 • Application 提供不同文件类型支撑不同上层应用数据组织形式 • PageFile/AppendFile/AppendECFile • Segment • 逻辑概念，空间分配的基本单元 （减少元数据数量） • 多个连续地址空间chunk（物理文件）的聚合数据组织形式 • CopySet • 逻辑概念 • 减少元数据数量 • 数据放置的基本单元 • 提高数据可靠性 • 包含多个chunk • 减少复制组数量 类似Ceph中的PG • 地址空间到—>chunk: 1 : N chunk有先后关系 • 创建时指定大小，lazy分配chunk • 提供4kb随机读写能力 • 支撑块设备应用场景 块设备层面的快照功能 即为文件层面快照数据组织形式 • AppendFile • 地址空间到—>chunk: 1 : 1 • 采用append的方式写入数据组织形式 • AppendFile • 地址空间到—>chunk:

。 19 > Nacos 架构 内核层  插件机制：实现三个模块可分可合能力，实现扩展点 SPI 机制，用于扩展自己公司定制。  事件机制：实现异步化事件通知，SDK 数据变化异步通知等逻辑，是 Nacos 高性能的关键部分。  日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮 助文档。  回调机制：SDK 通知数据，通过统⼀的模式回调用户处理。接口和数据结构需要具备可扩展性。 ${prefix}-${spring.profiles.active}-${file-extension} 配置快照（Configuration Snapshot） Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时，可以使 用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit，也类似于缓存，会 在适当的时机更新，但是并没有缓存过期（expiration）的概念。 可以提供发布配置、更新配置、监听配置等功能。 3. SDK 通过 GRPC 长连接监听配置变更，Server 端对比 Client 端配置的 MD5 和本地 MD5 是否相等，不相等推送配置变更。 4. SDK 会保存配置的快照，当服务端出现问题的时候从本地获取。 配置资源模型 Namespace 的设计就是用来进行资源隔离的，我们在进行配置资源的时候可以从以下两个角度来 看：  从单个租户的角度来看，我们要配置

管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化 QEMU、Curve-NBD：上层应用   FileManager：提供接口，记录已挂载卷  FileInstance：对应一个已挂载的卷  LeaseExecutor：负责定期与MDS通信，获取卷的元数据信息  元数据信息在打快照时会进行变化  MetaCache：元数据缓存  IOTracker：跟踪一个上层IO请求  IOSplitor：IO转换拆分  ChunkClient、CliClient：与Chunkserver进行通信 数据面：AioWrite/AioRead、Write/Read  控制面：Create/Delete、Open/Close、Rename等  IO处理：转换、拆分、合并  元数据获取及缓存  逻辑chunk与物理chunk映射关系  物理chunk所属的复制组(copyset)  复制组所在的chunkserver列表  复制组的leader信息  Failover支持 

管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块 新版本ChunkServer性能优化Curve ChunkServer是数据节点， CliService。成员变更相关操作 • CopySetService。创建copyset等操 作 • RaftService。Braft内置的service， 完成raft成员之间的选举，日志复制， 安装快照等操作。 ChunkServer架构CopysetNode封装了braft的Node，并 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 apply后再执行后面的操作。 ChunkServer架构CloneManager主要负责克隆相关的功 能，内部是一个线程池，主要负责异 步完成克隆chunk的数据补全。关于克 隆相关的内容将会在快照克隆相关介 绍文档中详细介绍。 ChunkServer架构Metric统计模块使用brpc中的bvar计数 器，统计一些IO层面和copyset层面的 一些指标，方便监控和跟踪。 Chun

或数据结构，这对于在要使用 multiraft 的场景下，每个 raft 实例需要独立的快照并不合适 如果改造 redis，初步评估了下，其工作量要比自己实现持久化的逻辑要大一些，改造主要是为了让 redis 提供单独 dump/load 一个 DB 的功能： 如果改造，dump/load 的逻辑都得动，而且会牵扯到一些其他逻辑（如主从复制，因为 redis 主从全量复制发送的就是一整个 RDB 文件，即 文件，即使我们不需要这个功能，这部分代码也是有耦合的）© XXX Page 11 of 12 1. 2. 3. 如果自己实现，只是一个简单的 sava/load 逻辑，比较清晰 redis 中有许多数据结构可供使用，如 (哈希、列表、set、sort_set)，但对于目前的需求来说，我们内存数据结构使用的是 C++ STL 中的哈希表（unsorted_map），之后有可能根据需求换成