TIKV

Kinger2026/7/29大约 4 分钟

在上一节剖析 JuiceFS 的架构时，我提到在海量规模下，JuiceFS 的元数据引擎会从 Redis 切换为 TiKV。

如果用一句话来定义它：TiKV 是一个开源的、分布式的、支持强一致性和分布式事务的键值（Key-Value）数据库。 它由著名的国产开源团队 PingCAP 打造，目前已经是云原生计算基金会（CNCF）的顶级毕业项目。

如果说 Redis 是跑在单机内存里的“顶级跑车”（极速但容量受限且容易丢数据），那么 TiKV 就是一列可以无限加挂车厢的“重型高铁”（跑在 SSD 上，容量无限扩展，且数据绝对不会错）。

以下为你硬核拆解 TiKV 的底层架构和核心黑科技：

TiKV 的设计极为优雅，它把极其复杂的分布式存储问题，拆解成了三个高度解耦的模块：

TiKV 不会自己去造单机读写硬盘的轮子。在每一个 TiKV 节点（物理机）的底层，它直接内嵌了 Facebook 开源的单机存储引擎之王——RocksDB。

你存入 TiKV 的任何 Key-Value 数据，最终都是交由底层这块石头（RocksDB）以 LSM-Tree（日志结构合并树）的数据结构，死死地刻在本地的 NVMe 闪存盘上。

单机存数据容易，但如果机器炸了怎么办？必须做多副本。TiKV 采用了大名鼎鼎的 Raft 共识算法。

传统痛点：如果你把一万 TB 数据当成一个整体去跑 Raft，系统早就卡死了。
TiKV 的魔法（Multi-Raft）：TiKV 会把所有的 Key 按照顺序切分成无数个连续的切片，每个切片叫做一个 Region（默认 96MB）。

然后，TiKV 为每一个 Region 独立运行一套 Raft 协议。你的集群里可能有几十万个 Region，就有几十万个互不干扰的 Raft 副本组在并行工作。如果某台机器宕机，只会影响它上面的那部分 Region，其他 Region 瞬间就会在别的机器上选出新的 Leader 接管读写，整个过程对上层完全透明。

当你的集群达到几百台服务器、几百万个 Region 时，数据放在哪台机器上最合适？如果某台机器快被撑爆了怎么办？

TiKV 架构中有一个独立的大脑叫做 PD (Placement Driver)。它在全局俯瞰整个集群：

负载均衡：如果 PD 发现 A 机器的 Region 太多，它会自动指挥把部分 Region 悄悄搬迁到比较空的 B 机器上。
热点打散：如果某个文件（Key）突然被疯狂读取（比如大模型训练瞬间同时读取某个 Manifest 账本），PD 会立刻发现这个“热点 Region”，并把它分裂、打散到多台机器上，用整个集群的吞吐去扛这个热点。

这是 TiKV 区别于普通 NoSQL（比如 Cassandra 或 HBase）最强悍的地方。

在分布式系统里，假设你要同时修改 A 机器上的 Key1 和 B 机器上的 Key2。如果 Key1 修改成功了，但在修改 Key2 时网络断了，数据就产生了“撕裂”。

TiKV 基于 Google 的 Percolator 事务模型 实现了强一致性的分布式事务。它引入了全局的时间戳（TSO），保证了跨机器的多次修改，要么全部成功，要么全部回滚（撤销）。这让 TiKV 拥有了媲美传统关系型数据库（MySQL/Oracle）级别的数据安全性。

回到我们之前的 DataOps 与 AI 存储架构中。

如果你使用 JuiceFS 管理大模型数据，初期用 Redis 当元数据引擎非常爽，因为快。但当你积累了 10 亿张图片（10 亿个文件）时，Redis 的痛点就爆发了：

内存撑爆：10 亿个文件的目录树，大概需要吞噬几百 GB 甚至上 TB 的纯内存，硬件成本极其昂贵。
宕机灾难：Redis 哪怕做了 RDB/AOF 持久化，在海量数据下重启恢复也需要很久，甚至可能丢失最后一秒的元数据（导致你的 OSS 孤儿文件泛滥）。

这时候，你只需在后台把 JuiceFS 的元数据引擎从 Redis 零缝隙切换为 TiKV：

成本骤降：TiKV 的数据是存在本地 NVMe 盘（RocksDB）上的，不再吞噬昂贵的内存空间。
无限扩展：10 亿个文件？100 亿个文件？没关系，加几台普通的物理机，TiKV 的 PD 会自动把新产生的元数据 Region 调度到新机器上，容量无上限。
绝对安全：依靠 Multi-Raft 和分布式事务，即使你直接拔掉两台服务器的电源，JuiceFS 的文件目录结构和权限属性也绝对不会产生一丝一毫的混乱。