TiKV核心原理：分布式事务KV存储

可视化演示

演示TiKV核心机制，包括Raft多副本一致性、MVCC多版本并发控制、Percolator分布式事务模型和Region分裂调度，通过交互式可视化展示分布式存储底层原理。

总体架构

想象你是那座超大城市联盟图书馆的第一任总馆长。市民不需要知道书放在哪个分馆，他们只面对一个统一的“检索台”。为了让这套系统能无限扩张，你不会把全城书目抄成一本大厚册子，而是把书架按照编号切成许多连续的区块，每块配三位馆员负责。这正是 TiKV 的顶层设计思路：把数据切成一格一格的 Region，每个 Region 就是一段连续键值的“书架”。

从数据模型看，TiKV 是一个 Key-Value 存储：每个数据项都是一对 (key, value)，其中 key 是二进制字符串，value 是字节数组。所有 key 按字典序排列，被切分到不同的 Region 中。每个 Region 默认由 3 个副本组成，这 3 个副本分布在不同的物理节点上，构成一个 Raft 复制组，共同对外提供“这一个 Region 不丢数据”的承诺。

整套系统在逻辑上分为四层：最底层用 RocksDB 做单机持久化存储；往上是 Raft 层，负责副本间的日志复制与一致性；再往上是事务层，实现分布式事务；最顶上是 PD（Placement Driver），负责记录每个 Region 的位置、管理分裂与故障迁移。分层设计的妙处在于，每一层都可以独立演进，就像图书馆的采购、编目、馆际互借各有专人负责一样。

回到图书馆的比喻：只有当每格书架都边界清晰、责任到人，整座联盟图书馆才能永远保持“无论书在哪个分馆，市民总能找到它”的承诺。TiKV 的顶层架构，归根结底做的就是这件事。

Raft一致性

三个分馆各存了一本《国富论》，但其中一本被读者做了批注，另外两本没有。你作为馆长必须规定：到底哪一本才是“官方版本”？如果每次有读者来问，都临时开三方会议，效率太低。于是你指定：平时由“主馆”负责对外回答，但它改书之前，必须把改动同步给其他分馆，得到多数确认后才能正式生效。这就是 Raft 协议的核心思路。

Raft 是 TiKV 中每个 Region 副本组使用的共识算法。它把一个复制组里的节点分成三种角色：Leader（主副本）、Follower（从副本）和 Candidate（竞选者）。正常情况下，只有 Leader 接收客户端写入，它把写操作追加为一条日志，并行发给所有 Follower，等多数派节点确认后，才把这条日志“提交”并应用到状态机。如果 Leader 宕机，Follower 会通过选举选出新 Leader，选举同样遵循多数派原则。

Raft 的核心价值在于“让多数派说了算”。它解决了三个子问题：Leader 选举、日志复制、成员变更。成员变更允许在不中断服务的情况下增减副本，比如把一个 Region 从 3 副本扩容到 5 副本。整个过程不需要人工指定谁当主，系统自己就能达成一致——就像图书馆联盟的总馆名号不是永久固定的，谁的能力获得多数分馆认可，谁就接班。

分馆之间核对抄本、按多数派盖章生效，听起来繁琐，却换来一个极其宝贵的性质：只要多数派节点还活着，整组服务就能继续。图书馆不会因为一家分馆临时停电就关门，TiKV 也不会因为一台机器宕机就丢数据。

MVCC机制

图书馆的借阅卡片上，如果管理员每次都在同一格里涂改，借阅者就无法知道“上次归还时书是什么状态”。于是你规定：每一次借出、归还、续借都追加一行记录，标注时间和操作人。读者查询时，系统只展示“他查询那一刻之前最接近的一条有效记录”——这就是多版本并发控制（MVCC）在图书馆里的样子。

在 TiKV 中，每个 key 可以同时存在多个版本的数据，每个版本都带有一个全局递增的提交时间戳 commit_ts。当事务读取某个 key 时，它会携带一个 read_ts（读取时间戳），存储引擎只返回满足“commit_ts ≤ read_ts”的最新版本。这样，一个长时间运行的事务也能看到一致的快照，而不会被其他并发写入干扰。

MVCC 最大的收益是“读写互不阻塞”：写操作永远追加新版本，不覆盖旧版本；读操作永远在旧版本快照上进行，不需要加锁。这样一来，在线业务最常见的读多写少场景就不会因为锁竞争而卡顿。不过，版本越积越多会浪费空间，因此 TiKV 会定期做垃圾回收，清理那些“任何活跃事务都看不到”的旧版本。

图书馆的读者永远看不到“正在被涂改的那一行”，看到的是他进门那一刻之前最完整的记录。MVCC 的智慧正是如此：用历史版本的叠加代替就地修改，让并发不再是敌人，而是秩序的一部分。

事务模型

一位市民在分馆 A 还掉旧书，同时想从分馆 B 借走另一本书。这两个操作必须“要么都成功、要么都不成功”——否则就会出现书丢了却没借到的混乱。馆长定下一个两步协议：第一步，先在两个分馆的账本上写下“此书正在处理中”的锁定标记并预登记；第二步，等两边都确认无误，再盖上“正式生效”的章，同时解除锁定。这个协议，就是 Percolator 两阶段提交模型的现实原型。

TiKV 的分布式事务基于 Google 的 Percolator 论文设计，核心目标是在没有全局锁的前提下，让跨多个 Region、多个 key 的写入拥有原子性。事务开启时先获取一个 start_ts；提交时获取一个更大的 commit_ts。流程分为两阶段：预写（Prewrite）阶段，事务向每个涉及的 key 写入一个带 start_ts 的预存值，并尝试加锁；如果任何 key 的锁已经被其他事务占用，则整个事务回滚。提交（Commit）阶段，所有预写成功后，事务用 commit_ts 打上最终时间戳，释放全部锁，数据对外可见。

这种设计最精妙的地方在于：没有任何中央协调者，每个 key 的锁自包含在自己的记录里。读操作遇到锁时，只需根据锁中的 start_ts 判断持有锁的事务是否已经超时，进而决定等待还是清理。由于 commit_ts > start_ts，所有并发事务都能依据时间戳形成唯一的历史顺序，不会出现“先提交却后可见”的错乱。

借书协议里的“先锁定、后盖章”，映射到数据库就是“先预写、后提交”。它让所有分馆的账本在任意时刻都能达成一致——哪怕没有一个中央指挥官，每个馆员也清楚自己该做什么。

Region管理

一万本书堆在同一格书架上，不但找书困难，搬运也极慢。馆长定下规矩：每个书架区块的书目数量超过上限，就必须自动拆成两个新块，分别挪到不同分馆。TiKV 的 Region 分裂逻辑与此几乎完全相同。

TiKV 中每个 Region 默认约 96MB 数据。当 Region 的数据量超过这个阈值时，PD 会指示该 Region 的 Leader 执行分裂操作：把键值范围从中间一分为二，生成两个大小相近的新 Region。分裂过程不需要拷贝数据，因为新 Region 只是改变了键空间的边界，底层存储仍然共享同一份 RocksDB 数据。分裂完成后，新的 Region 元数据会注册到 PD，客户端通过 PD 获取最新的路由信息。

Region 分裂的意义在于“控制单点容量上限”。单个 Region 过大会导致三个问题：一是参与复制的数据量增大，网络和 IO 压力上升；二是热点集中在一个副本组，无法发挥分布式优势；三是故障恢复时补副本的时间变长。通过自动分裂加上 PD 的负载均衡调度，TiKV 能把数据均匀地铺到整个集群中。当某个节点存储接近饱和，PD 还会把 Region 调度到空余节点，这就是所谓的“热点调度”——它会监控读写流量的分布，把热 Region 分散到更多机器上。

书架拆块看似小事，却是联盟图书馆能无限扩容的秘密。因为每一块书架都足够小，搬迁、复制、重新平衡的成本都可控；反过来，TiKV 也靠这套“拆块”机制，让上百台机器的集群像一台巨型计算机一样顺畅运转。

高可用机制

某个深夜，一家重要的分馆突发水管爆裂，书架全部被淹。作为总馆长，你不会让大家等着修好——而是立刻启动预案：从其他分馆调出这本书的备份副本，在新分馆重建书架，同时对外保持“开门营业”的状态。TiKV 的高可用机制，就是这套预案的工程化实现。

在 TiKV 集群中，PD 通过心跳机制检测每个节点的健康状态。如果某个 store 节点心跳超时，PD 会判定它失联，并为其负责的每个 Region 生成“补副本”任务：选择集群中另一个健康节点，从已有副本同步数据，把新的副本建立起来。这个过程依赖 Raft 的成员变更能力，先添加新副本、再移除故障副本，整个过程对客户端透明。

那么，系统到底能容忍多少个节点同时故障？答案取决于副本数。一个 3 副本的 Region，最多容忍 1 个副本故障；5 副本的 Region，最多容忍 2 个。因为只要多数派存活，Raft 就能继续选主、继续提交日志。故障期间读写可能短暂变慢，但不会停机——这就是“无感切换”的含义。数据恢复则依靠日志的追平机制：新副本加入后，Leader 会把缺失的日志项同步过去，直到它与 Leader 状态一致。

回看图书馆的比喻：分馆可以坏，但书不能丢。TiKV 用“多副本 + 多数派 + 自动补位”三重保险，把故障从“事故”变成“日常调度里的一件小事”。这正是分布式系统高可用的本质：不是不故障，而是故障之后能自行恢复。

AI 应用场景

Python 演示

#!/usr/bin/env python3"""TiKV核心机制模拟：极简MVCC存储 + 两阶段提交事务。""" from collections import defaultdict  class MVCCStore:    """用Python模拟TiKV的多版本存储与事务提交语义。"""     def __init__(self):        self.data = defaultdict(list)  # key -> [(commit_ts, value)]        self.locks = {}                # key -> start_ts，模拟prewrite锁        self.ts = 0                    # 全局逻辑时间戳     def next_ts(self):        self.ts += 1        return self.ts     def get(self, key, read_ts):        """读取时间戳下最新可见版本。"""        for commit_ts, value in reversed(self.data[key]):            if commit_ts is not None and commit_ts <= read_ts:                return value        return None     def prewrite(self, key, value, start_ts):        """事务阶段一：加锁并写入预提交版本。"""        if key in self.locks:            raise RuntimeError("write-write conflict")        self.locks[key] = start_ts        self.data[key].append((None, value))  # 未提交版本以None标记     def commit(self, keys, start_ts, commit_ts):        """事务阶段二：生效提交，并释放锁。"""        for key in keys:            self.locks.pop(key, None)            for i, (ts, val) in enumerate(self.data[key]):                if ts is None:                    self.data[key][i] = (commit_ts, val)                    break  def main():    store = MVCCStore()     t1 = store.next_ts()    store.prewrite("user:1:age", "20", t1)    store.commit(["user:1:age"], t1, store.next_ts())    read_older = store.next_ts()    print("第一次读到的age:", store.get("user:1:age", read_older))     t2 = store.next_ts()    store.prewrite("user:1:age", "21", t2)    store.commit(["user:1:age"], t2, store.next_ts())    read_newer = store.next_ts()    print("第二次读到的age:", store.get("user:1:age", read_newer))    print("旧时间戳仍读到旧值:", store.get("user:1:age", read_older))  if __name__ == "__main__":    main()

1. self.data = defaultdict(list)每个 key 对应一个版本列表，存放 (commit_ts, value) 元组。
2. def get(self, key, read_ts)从最新往旧遍历版本，返回第一个 commit_ts ≤ read_ts 的已提交值。
3. if commit_ts is not None过滤掉尚未提交的预写版本，保证读操作看不到“半成品”。
4. self.locks[key] = start_ts模拟预写阶段的锁，以 start_ts 记录持有者。
5. self.data[key].append((None, value))用 None 标记未提交版本，对应 TiKV 中的 prewrite 数据。
6. def commit(self, keys, start_ts, commit_ts)把 None 替换为 commit_ts，版本正式生效。
7. store.get("user:1:age", read_older)即使新版本已提交，旧读取时间戳依然读到旧值，这就是 MVCC 快照隔离。

常见误区

面试题