云原生存储架构：TiDB分布式SQL

可视化演示

演示 TiDB 三层分布式架构：计算存储分离，TiKV 多节点 Raft 共识保证强一致，PD 调度 Region 分裂与均衡，实现水平扩展与 HTAP 混合负载。

TiDB架构总览

想象你经营的那家连锁快递公司：每个城市都有门店负责收件发件，几大区域各有一座自动化仓库负责存件，总部还有一间调度办公室记录全局信息。TiDB的设计几乎是这套结构的翻版——TiDB Server就是那些“门店”，TiKV是“仓库”，PD是“调度办公室”。三者各司其职，互不拖累，这正是它区别于传统单机数据库的第一性原理。

传统MySQL里，一台服务器既当“门店”又当“仓库”，数据一多就爆仓。TiDB的第一步改革就是拆开这两件事：TiDB Server是纯计算层，只负责解析SQL、生成执行计划、把请求路由到正确的数据节点；TiKV是纯存储层，只负责以键值对形式持久化数据。由于计算层不存任何数据，它天然“无状态”——你可以随时增加十台八台TiDB Server来分担查询压力，就像旺季多开几个临时窗口，完全不用搬动仓库里的任何包裹。

这带来了两个直接收益。第一，水平扩展变得极简单：计算不够加计算节点，存储不够加存储节点，互不干扰。第二，TiDB向上兼容MySQL协议，你现有的MySQL客户端、连接池、ORM框架几乎零改动就能接入。客户看到的还是熟悉的“寄件单”，只是背后处理订单的从一家小店变成了一整张全国物流网。当然，“拆开”只是第一步，一个SQL查询被拆成哪些子任务、由哪些TiKV节点协作、数据散落何处，这些复杂性被PD与TiKV的底层机制稳稳接住了，接下来我们逐层拆解。

回到快递公司：门店加多了，接单能力自然上去，但包裹能否准时送达，还得看后端的仓库和调度。TiDB的奥义正是“各管一摊，摊摊可扩”。

TiKV存储引擎

现在走进那间自动化仓库——TiKV。货架上每一格都有唯一编号（key），格子里放着对应商品（value），这就是最朴素的“键值对”概念。TiKV本质上是一个分布式Key-Value存储引擎，所有表数据最终都会变成键值对，按key排序后存进无数个TiKV实例。

但仓库有个麻烦：盘点商品（读操作）时，不能因为某个工人正在上架新货（写操作）就暂停整个仓库的运转。TiKV引入MVCC（多版本并发控制）解决这个矛盾——每个key的每一次修改都会生成一个新版本“入库记录卡”，卡片上盖着写入时间戳（ts）。读操作只需找到“不晚于自己读时间戳”的最新版本，就可以无锁地读到一份一致性快照。正在写入的事务对其他读者不可见，读写互不阻塞，就像理货员看到的历史账本永远是一致完整的。

底层落盘方面，TiKV采用LSM-Tree结构。新写入先进入内存中的“跳表”，攒够一批再批量刷到磁盘，形成分层的数据文件。LSM-Tree把随机写转化为顺序写，让机械硬盘和SSD都能发挥最大顺序吞吐——这正是TiKV能扛住高并发写入的隐藏武器。打个比方：仓库不会为每个小包裹单独跑一趟车，而是装满一整车再发，运输效率因此大幅提升。

仓库里的每个货架格都贴着若干张不同时间的“入库记录卡”，读的人挑最新的看，写的人继续贴新卡，彼此不抢笔——这就是MVCC的温柔之处。

Raft一致性协议

仓库里最重要的资产是数据，绝不能因一台机器宕机就丢失。TiKV的解法是：每个“货架区”（Region）的数据都复制三份，放在不同机房的TiKV节点上，三个副本组成一个小队，叫Raft Group。小队里有一个“队长”（Leader）和两个“队员”（Follower），所有写请求必须先到队长那里。

Raft协议要解决的核心问题是：三个副本都声称自己是最新的，听谁的？答案是“多数派说了算”。队长收到写入请求后，先把日志（写操作记录）发给两个队员，当至少2个节点（超过3个的一半）确认收到后，这条日志才算真正提交。为什么多数派规则如此重要？因为在任何时刻，不可能同时存在两个“过半数”的阵营——就像快递公司开全国会议，只要超过半数门店到会，会议就有效，且不可能同时有另一场也过半数到会的“分会”被认定为有效。

如果队长宕机，剩下的两个队员中会快速选举出一个新Leader，继续对外服务。整个过程对业务几乎透明：客户端只需访问Leader，Leader挂掉后自动切换。这就是Raft的三大核心动作——Leader选举、日志复制、多数派提交——共同保障了分布式环境下数据的强一致性，同时容忍单节点故障。快递公司里货架区哪怕有一个仓库失火，另外两个仓库的存根也能还原一切。

多数派不是简单的“少数服从多数”，而是用数学上的超半数保证了任何两个决策阵营必然有交集——这是分布式系统互斥共识的基石。

Region分片机制

仓库再大也有装满的一天。TiDB把数据按key的连续范围切分成一个个标准尺寸的“货架区”，每个货架区称为一个Region，默认上限96MB。当某块货架区数据持续写入、逼近容量时，它会自动从中间“一分为二”，变成两个相邻但完全独立的Region。这就是TiDB数据自动分片的核心机制：Region分裂。

分裂过程非常轻量：TiKV检测到Region超过阈值后，在本地选定一个分裂点，把原key区间[a, c)切成[a, b)和[b, c)两段，各自生成新的Region元数据。分裂本身几乎不搬动数据——只是逻辑上的一刀，就像在快递柜里插入一块隔板，把一格变成两格，货物不用搬出去。分裂后，PD调度中心会为新的Region补充副本，并把多余的副本迁移到其他TiKV节点上，让整个集群的负载保持均衡。

更关键的是，Region是TiDB数据均衡与容灾的最小单位。每个Region都有独立的Raft三副本，分布在不同的可用区或机房。某个机房整体断电，该Region的Leader会瞬时切换到另一个机房的副本上，业务无感知。Region分裂让数据像水流一样自然摊平在所有节点上，新增机器后PD会自动把一部分Region调度到新节点，无需任何人工拆库拆表。这也是TiDB对比传统分库分表中方案最优雅的地方——分片不是DBA设计的，而是数据自己“裂”出来的。

货架区的“自动裂变”让TiDB无需人工分库分表就能水平扩展——你只管往仓库里堆货，货架自己会分格，调度员会自动把货架匀到各个分仓。

PD调度中心

PD是快递总部的“指挥室”，全称Placement Driver。它手里握着一张“大数据地图”：每一个Region的副本分别在哪台TiKV节点上、谁是Leader、节点健康状况如何。当TiDB Server收到一条SQL，需要第一时间向PD询问“这笔数据在哪个仓库的哪块货架区”，PD回复之后SQL才能精准路由。

PD的第二项核心职责是调度。它持续收集各TiKV节点的Region数量和负载指标，一旦发现某节点Region过多或磁盘即将写满，就会挑选若干Region，把它们的副本迁移到空闲节点上，再把Leader也转移过去。整个过程完全后台自动运行，业务无感知。这就像总部看到A仓库货架快塞满、B仓库空空如也，会立刻安排货车把一部分货架整体搬过去。

PD的第三项职责是分发全局时间戳TSO。分布式环境下，多个节点同时发起事务，必须有一个全集群统一的“时钟”来为事务排队和排序，否则“先写后读”的因果顺序就乱了。PD通过“物理时间左移18位+逻辑计数”的方式，为每个事务分配一个全局唯一且严格递增的时间戳。所有节点用这个TSO作为MVCC和多版本的时间标签，就仿佛全国所有快递单都盖着总部的统一钢印——任何两单之间都能比出先后。

调度中心不搬一件货，但它知道每件货在哪，决定货往哪搬，还给每单盖上唯一的“时间钢印”——这就是PD的三重身份：地图、调度员、钟表匠。

分布式事务

快递公司里有一个最棘手的场景：一个订单涉及到多个货架区的商品——比如买手机的同时办了合约套餐，手机在A货架区，套餐权益在B货架区。要保证这笔订单要么全部生效、要么全部不生效，绝不能出现手机发货了、套餐没办上的尴尬。TiDB用“两阶段提交”（2PC）解决跨Region的原子性问题。

第一阶段叫Prepare（预占）：事务协调者把“预占通知”发给所有涉及到的Region，每个Region在本地的Raft组内完成预写和锁标记，然后回复“准备好了”。如果有任何一个Region无法完成预占（比如锁冲突），协调者就广播Abort，所有Region回滚，不留痕迹。第二阶段叫Commit（确认）：所有Region都回复Ready后，协调者广播Commit，各Region正式提交。TiDB的2PC还有一个巧妙细节：事务的提交时间戳TSO在Prepare阶段就已确定，所有Region都用同一个TSO提交，保证全局一致的快照视图。

TiDB的事务模型默认采取乐观锁思路——事务执行过程中不长时间持有锁，只在最终提交时检查冲突。如果冲突发生，让事务重试而不是死等，配合PD分发的TSO做冲突检测。在多数场景下，一个事务涉及的数据如果恰好都落在同一个Region内，TiDB会自动退化为“本地事务”，直接一轮Raft提交搞定，连两阶段都不用走。这也是为什么TiDB作为分布式数据库，在单点小事务上与单机MySQL的差距并不悬殊。

跨货架区的订单，靠的就是“先各方预占、再统一确认”的流程——想象所有分店先盖章确认“这批货我先锁定了”，总部收到全部盖章后才正式放行，任何一家反悔则全单作废。

部署与实践

理解了TiDB的原理，最后看如何落地。早期部署分布式数据库往往令人头大：要装好几个组件、配置网络、处理高可用，门槛极高。TiDB官方推出的TiUP工具让这一切变得像用手机点外卖一样简单——一条命令即可拉起一个高可用集群，生产环境最少3台机器就能跑起来，单机还能用tiup playground起一个仿真小集群用于学习开发。

水平扩展是TiDB最直观的实践体验：当集群容量不足时，新加几台TiKV节点，PD自动把部分Region迁到新节点，整个流程无需停服。你不需要像传统分库分表那样预先规划分片数，也不需要修改任何SQL——Region自己会裂变，PD自己会搬货。TiDB Cloud和TICloud Serverless还提供了全托管模式，连机器都不用自己买，按量付费就能获得一个云原生分布式数据库。

高并发写入场景是TiDB的主场：订单流水、支付流水、IoT设备上报等写多读少的业务，传统单机MySQL通常扛到每秒几千笔写入就开始报警，而TiDB通过把写入分散到大量Region和TiKV节点上，轻松支撑每秒几十万甚至上百万的写入吞吐。运维侧，TiDB Dashboard提供可视化监控页面，Region分布、热点Region、慢查询、GC状态一目了然。整个学习路径可以浓缩为一句实践心法：先用TiUP拉起一个小集群，往里面灌数据，观察Region如何自动分裂，再尝试加一台TiKV节点看看数据如何流动——亲手演示一遍，胜过一百页文档。

快递公司从一个小城扩张到全国，靠的不是把一个仓库无限加高，而是不断开新仓、上新货架、由调度中心自动平衡——TiDB的实践哲学，与这个逻辑完全同构。

AI 应用场景

Python 演示

import random class RaftNode:    """简化版Raft节点,只模拟日志复制与票数统计"""    def __init__(self, nid, peers):        self.nid = nid        self.peers = peers        self.log = []     def append_entry(self, entry):        """Leader本地追加一条日志"""        self.log.append(entry)     def replicate_to_peers(self, entry):        """复制日志到所有Follower,统计确认票数"""        self.append_entry(entry)        votes = 1  # Leader自己算一票        for peer in self.peers:            if random.random() > 0.05:  # 模拟极少数丢包                peer.log.append(entry)                votes += 1        return votes     def try_commit(self, votes, need):        """票数达到多数派阈值则提交成功"""        return votes >= need  def build_cluster(size=3):    nodes = [RaftNode(i, []) for i in range(size)]    for node in nodes:        node.peers = [p for p in nodes if p.nid != node.nid]    return nodes  def main():    size = 3    need = size // 2 + 1    nodes = build_cluster(size)    leader = nodes[0]    print(f"集群共{size}节点,Raft多数派阈值={need}")     for i in range(1, 8):        entry = "txn-%02d" % i        votes = leader.replicate_to_peers(entry)        ok = leader.try_commit(votes, need)        status = "COMMIT" if ok else "ABORT"        print(f"写入{entry}:{votes}/{size}票->{status}")        assert ok, "日志复制失败,无法提交"  if __name__ == "__main__":    main()

1. need = size // 2 + 1计算多数派阈值，3节点集群需要2票才能提交。
2. leader.replicate_to_peers(entry)Leader把新日志发给所有Follower并统计确认票数。
3. ok = leader.try_commit(votes, need)当确认票数达到阈值时日志才提交，否则整体失败。
4. peer.log.append(entry)Follower在本地落一条日志，模拟数据副本的写入。
5. status = "COMMIT" if ok else "ABORT"用状态标识直观展示每条日志的最终结论。

常见误区

面试题