深入TiDB分布式架构与存储引擎

可视化演示

动态演示深入TiDB分布式架构与存储的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

整体分层架构：把门店与仓库分开

「TT茶饮」扩张到第 50 家店时，你发现真正的瓶颈不是奶茶配方，而是每家店都得囤一大堆原料：珍珠、茶底、果酱、冰块……新店开业光备货就要一周。于是你做了一个大胆决定——砍掉所有门店的后厨，改成「中央原料仓＋多点单员」模式：门店只留点单员，原料全部集中到几个大仓库，谁接单谁去仓库取料。TiDB 正是这个思路：把「计算」和「存储」分离，各自独立扩展。

这个思路落到技术上，就是 TiDB 的三层架构：最上层是无状态的 TiDB Server（点单员团队），负责接收业务发来的 SQL 请求、解析语法、生成执行计划；中间是 PD（总调度台），负责记录数据分布在哪些仓库、分配全局时间戳；最下层是 TiKV（中央原料仓），真正保存数据。TiDB Server 不存任何业务数据，因此它「无状态」——服务器崩溃了，重新拉起一个空实例就能继续服务，就像换一批点单员，业务不受影响。

「无状态」带来了一个杀手级优势：可以像搭积木一样水平扩展。业务量翻倍？把 TiDB Server 从 3 台加到 6 台，前端负载均衡器自动分流；存储不够了？给 TiKV 集群加节点，数据自动按 Region 重新分布。这种「计算加人、存储加仓」的灵活扩容方式，是传统分库分表方案难以做到的。

回到奶茶店的比喻：你不需要给每家新店重新建仓库，只要「增聘点单员＋共享中央仓库」，开店速度自然甩开同行。TiDB 的存算分离，让计算资源与存储资源像两条独立的流水线，按需扩充、互不拖累。

PD调度中枢：总部手里的「小包分布簿」

原料集中到中央仓库后，新问题来了：仓库不只一个，珍珠放在 A 仓，果酱放在 B 仓，而一杯「珍珠奶茶」需要同时取两边的料。点单员不可能记住所有原料的位置，于是总部设了一个调度台——它手里有一本「小包分布簿」，记录着每一包原料（Region）放在哪个仓库、当前由哪个仓库的哪个货架负责。点单员接单后先问调度台，再精准取料。

这个调度台就是 PD（Placement Driver）。它负责三件大事：第一，维护「key→Region→存储节点」的路由表，让每个请求都能快速找到数据；第二，分配全局单调递增的时间戳 TSO，给事务排序用的「时钟」；第三，持续做调度——发现某个仓库太忙，就把部分 Region 迁到空闲仓库；发现某个 Region 的 Leader 副本负载过高，就把 Leader 角色转移。

TiDB 的数据不是一大块，而是按主键范围切成许多小片，每片叫一个 Region（默认最大约 96MB）。每个 Region 的 key 范围是一个左闭右开区间，就像把一本书按页码切成若干小册子，每一小册的页码范围清清楚楚。PD 的路由表就记录着：「第 100～199 页这本小册子，放在 A 仓库」。

有了调度台的「小包分布簿」，任何一台点单机都能在毫秒内问出原料位置。PD 本身也组成一个小集群（多数派机制），即使某台调度机宕机，调度台整体仍然可用——就像总部备了三本一模一样的分布簿，两本还在就能对账。

TiKV行式引擎：按「整杯茶」存原料

总部决定，每个中央仓库的货架按「一杯茶的完整配方」来摆放原料：一个货格放的就是「某杯珍珠奶茶所需的全部原料」——茶底、珍珠、奶盖、糖度，整整齐齐放在一起。点单员要制作这杯茶，只需按杯号取出一整格原料，一次拿齐。这就是 TiKV 的「行式存储」：一行数据的所有列（字段）连续存放在一起。

TiKV 本质上是一个分布式的 Key-Value 引擎，按 key 排序存储。底层采用 LSM-Tree（日志结构合并树）结构：新数据先追加写入内存中的有序表（MemTable），积累到一定量再批量刷到磁盘，因此写入是高效的顺序写。它不像传统 B+ 树那样在磁盘上随机修改旧数据，而是「只追加、后合并」，把随机写变成顺序写，这也是它能扛住海量写入的关键。

为了让读写并发不打架，TiKV 引入了 MVCC（多版本并发控制）：每次写入不是覆盖旧值，而是生成一个新版本，旧版本继续保留一段时间。这样读请求可以安心地读自己出发时的那个版本，写请求也可以在另一个版本上继续写，真正做到「读不阻塞写、写不阻塞读」。旧版本则由后台 GC（垃圾回收）进程定期清理。

回到茶饮店：TiKV 的货架整齐摆放着「一杯一杯」的完整配方，做一杯茶只需取一整格原料，所以点查（按主键取一行）极快。MVCC 则像配方册子只加新页、不改旧页——读的人看的永远是下单那一刻的配方，写的人继续在后面补新页，各不干扰。

Raft一致性协议：三家仓库对账的规矩

现在你有了多个中央仓库，但新的担心出现了：如果 A 仓库的珍珠被烧毁了，顾客的「珍珠奶茶」怎么办？于是你规定：每份重要原料（Region）必须同时在三个仓库各存一份，而且三份必须保持一致。这里的规矩就是 Raft 协议：三个仓库组成一个小组，其中一个被指定为「主仓」（Leader），另外两个是「从仓」（Follower）。顾客下单时，主仓把订单记进自己的台账，同时把同一笔订单广播给两个从仓，要求它们也记进台账。

Raft 的核心原则是「多数派决策」：主仓发出的订单日志，只要超过半数的仓库（3 个中至少 2 个）确认记好了，这笔订单就算成功提交，可以告诉顾客「下单成功」。剩下的那个仓库慢一点、甚至暂时宕机，都不影响这笔订单的成功。如果主仓突然失联，两个从仓会发起新一轮选举，票数过半的一方成为新主仓，继续服务。

这套机制的关键在于「少数服从多数」：只要多数派（quorum）活着，数据就不会丢，服务就能继续。副本数量越多容错能力越强，但成本和同步开销也越大。TiDB 默认每个 Region 保存 3 个副本，这恰好是「能容忍 1 个副本故障」的最小配置。

放在奶茶店场景里：三仓对账制度保证了「只要两家仓库还活着，你的奶茶配方就丢不了」。Raft 协议不是玄学，它就是一套清晰的「记账 + 投票」规则，让分布式系统在部分机器故障时依然稳如泰山。

TiFlash列式引擎：总部的分析台账

中央仓库解决了「做茶快」，但老板又提出新需求：我想知道上周哪种水果茶的销量最高、哪个门店的利润最薄。如果让点单员从三万个「整杯配方」的货格里翻找，查「所有配方里的水果用量」，效率简直灾难——因为分析往往只关心少数几个字段，却要扫描所有行的全部列。于是总部新设了一个「分析中心」：不按「一杯茶」记账，而是把「所有配方里的水果用量」单独记成一列台账，再按品类记账。

这就是 TiFlash 的列式存储：同一列的数据连续存放，读取时只需加载查询涉及的列，再配合列式压缩算法（同一列数据类型相同，压缩率远高于行式数据），分析查询的磁盘 IO 和 CPU 开销都大幅降低。列存天生为「大范围扫描＋聚合统计」而生。

但 TiFlash 的数据从哪来？它不能自己造数据，而是以 Raft Learner 的身份挂在每个 Region 的 Raft 组里。Learner 是一个特殊角色：它像从仓一样接收并应用主仓广播的日志，但不参与投票——因为它只是用来做分析的副本，投不投票不影响数据一致性，这样即使它暂时掉队，也不会拖累线上写入。TiFlash 通过异步复制主仓的 Raft 日志，把 TiKV 中的每一行变更同步到自己的列式存储中，做到近乎实时的数据新鲜度（秒级延迟）。

分析中心的台账虽然不负责做茶，但因为它专精「按类统计」，老板的报表需求几分钟就能出。TiFlash 用 Learner 身份「悄悄学习、不添乱」，既不参与投票影响一致性，又保证了分析数据的实时性——这正是 TiDB 敢于在一套系统里同时做交易和分析的底气。

HTAP混合负载：一套系统，两套账本

以前的 IT 系统通常要建两套：一套 OLTP（在线交易）负责处理订单、扣库存，一套 OLAP（在线分析）负责跑报表。数据得靠 ETL 任务每天深夜从交易库搬到分析库，老板看到的水远是「昨天的数据」。TT 茶饮想做一个改变：交易和分析用同一套系统，点单产生的数据秒级出现在分析台账里，老板随时能看「此刻哪款茶卖得最快」。这就是 HTAP（混合事务与分析处理）。

TiDB 的 HTAP 能力建立在「行列双格式」之上：同一份数据，在 TiKV 中以行式存储服务点查和小事务，在 TiFlash 中以列式存储服务聚合分析。当业务发来一条 SQL，TiDB 优化器会像一个「智能调度员」，先看查询的特征——如果是一个简单的主键点查，它走 TiKV，几十毫秒返回；如果是一个大表分组汇总，它走 TiFlash，利用列存和向量化计算快速出结果。优化器通过估算两种引擎的执行代价来选择更优路径，开发者也可以手工指定 Hint 强制选路。

两个引擎的数据通过 Raft 日志保持同步，TiKV 提交一笔写入，TiFlash 几乎同时通过 Learner 应用同一条日志。更妙的是，TiDB 在资源层面做了隔离与管控：分析任务跑在 TiFlash 上，不会抢占 TiKV 的交易资源，交易峰值时报表照跑不误。这就是「一套系统，两套账本，实时同步，互不干扰」。

回到茶饮集团：前台点单照常用「整杯配方」的取料方式（行存交易），老板的实时报表则从「品类台账」（列存分析）直接出数。两本账各司其职，数据又实时互通。TiDB 用一套系统干了过去两套系统的活，还不用等第二天的 T+1 数据——这就是现代 HTAP 数据库的魅力。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""TTDB: 模拟 TiDB 分布式写入与行列混合读取的教学示例"""import hashlib REGION_NUM = 2          # 模拟 2 个 RegionREPLICAS = 3            # Raft 三副本  def hash_key(key):    return int(hashlib.md5(key.encode("utf-8")).hexdigest()[:8], 16)  class RaftGroup:    def __init__(self, group_id):        self.group_id = group_id        self.logs = [[] for _ in range(REPLICAS)]  # 三个副本各自的日志        self.commit_index = 0     def append_entry(self, entry):        for i in range(REPLICAS):            self.logs[i].append(entry)      # 日志复制到所有副本        self.commit_index += 1        return self.commit_index            # 返回已提交位置  class Region:    def __init__(self, region_id):        self.region_id = region_id        self.rows = {}                       # 行式存储: key -> row        self.group = RaftGroup(region_id)     def put(self, key, row):        ok = self.group.append_entry(("put", key, row))        if ok < 2:            raise RuntimeError("副本未达多数派")        self.rows[key] = row                 # 提交后落盘（模拟 TiKV）  class ColumnarStore:    def __init__(self):        self.columns = {}                    # 列式存储: col_name -> [value]        self.sync_count = 0     def apply(self, row):        for col, val in row.items():            self.columns.setdefault(col, []).append(val)        self.sync_count += 1     def avg(self, col):        vals = self.columns.get(col, [])        return sum(vals) / len(vals) if vals else 0  def route(key, region_num):    return hash_key(key) % region_num  def main():    regions = [Region(i) for i in range(REGION_NUM)]    columnar = ColumnarStore()    for i in range(8):        key = "user_%d" % i        row = {"age": 20 + i, "city": "City_%d" % i}        rid = route(key, REGION_NUM)        regions[rid].put(key, row)          # 写入行存 TiKV        columnar.apply(row)                 # 同步到列存 TiFlash     key = "user_3"    rid = route(key, REGION_NUM)    row = regions[rid].rows[key]            # 点查: 只访问一个 Region    print("点查 user_3 ->", row)     print("全表平均 age =", columnar.avg("age"))  # 列存聚合  if __name__ == "__main__":    main()

1. hash_key(key)对主键做哈希，再取模路由到具体 Region，类似 PD 的路由表的简化版。
2. self.logs = [[] for _ in range(REPLICAS)]每个 Raft 副本有一条独立日志列表，模拟主仓广播日志给两个从仓。
3. self.logs[i].append(entry)将同一条写入日志复制到所有副本，对应 Raft 的日志复制阶段。
4. ok < 2检查提交位置是否达到多数派（3 副本中至少 2 个），否则抛异常，体现「多数派决策」。
5. self.rows[key] = row行式存储：key 到整行 dict 的映射，点查时一次取出完整一行。
6. columnar.apply(row)把同一列的值追加到列式存储对应列表中，模拟 TiFlash 的 Learner 异步同步。
7. regions[rid].rows[key]点查只需访问目标 Region，无需扫描其他 Region。
8. columnar.avg("age")聚合分析只读取 age 这一列，不需要扫描所有列，体现列存优势。

常见误区

面试题