NewSQL与向量数据库：TiDB整体架构

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

系统总览

小同的面馆升级为连锁集团后，立下三条规矩：第一，点单员和厨师只管接待，不管仓库；第二，食材全部放进冷链仓库，按箱分装，三仓各存一份；第三，运营经理手里攥着一本总台账，谁家缺货、谁家爆仓，都由他来调配。这套规矩，就是 TiDB 的顶层设计——计算存储分离。计算的人不碰数据，存储的人不碰业务，各司其职才能各展所长。

把面馆翻译成数据库：TiDB 集群由三种角色组成。TiDB 节点是前台的“点单员+厨师”，负责解析 SQL、生成执行计划，然后把活儿派下去；TiKV 是“冷链仓库”，以键值对（Key-Value）形式把数据分片存在多台机器上；PD 是“运营经理”，既管着数据分片的位置台账，又负责故障发现与负载调度。三者合在一起，对外却依然透出 MySQL 的熟悉味道——老顾客用的菜单、点菜的习惯全都不用改，这正是 TiDB 兼容 MySQL 协议的杀手锏。

这套架构带来最直观的好处是水平扩展：面馆生意火爆，与其把单店后厨扩到无限大，不如多开几家分店。TiDB 里加一台 TiDB 节点就多一份并发处理能力，加一台 TiKV 节点就多一份存储容量，理想情况下集群规模翻倍，吞吐量也接近翻倍。

当然，真实系统里网络开销、元数据同步会让这条曲线打点折扣，但 TiDB 的方向正是让 $T_{\text{总}}$ 尽量贴近这条理想直线。面馆的规矩立住了，后面的故事都从这三条规矩展开。

TiDB计算层

走进连锁集团的前厅，你会看见一群手脚麻利的点单员和服务员。客人报出一串菜名，点单员要听懂需求（SQL 解析），然后心里快速盘算：是先煮面还是先备料？需不需要让后厨并行出菜？（执行计划优化）这些前厅人员有个特点——他们身上从不带食材，下班拍拍手就能去任何一家分店顶班，这就是“无状态”。

在 TiDB 中，TiDB Server 就是这群前厅人员。一条 SQL 进来，第一步是解析：把“我要一碗牛肉面”这样的自然语言拆成语法树，检查语法对不对、字段存不存在。第二步是优化：生成多个执行计划，挑成本最低的那个。第三步是执行：把任务拆成子任务，分发给 TiKV 集群并行处理，最后汇总成结果端给客户端。整个过程对应用透明，应用以为自己只在跟一台 MySQL 说话，实际上背后有一整支分布式团队在协作。

无状态设计是 TiDB 计算层最优雅的地方。因为不存数据，TiDB 节点挂了，新节点秒级顶上，业务几乎无感；因为不存数据，TiDB 节点可以随意加减，前端接入层挂一个负载均衡，就能把请求均匀地分给所有活着的节点。集群的查询能力不再是单机的天花板，而是一群节点能力的叠加。

前厅团队越招越多，接待能力越来越强，但他们始终有个原则：只管接单传菜，绝不去仓库搬货。接下来，我们跟着食材，走进冷链仓库看看。

TiKV存储层

冷链仓库是连锁集团的命脉。为了让食材存取高效，仓库实行“编号定位”：每种食材对应一个编号（Key），编号后面跟着存放位置与数量（Value），一张巨大的键值对照表就是全部家当。这就是 TiKV 的存储模型——一份分布式的 Key-Value 大表，只不过这张表被拆成了无数个小格子，铺在多台机器的磁盘上。

每个小格子，在 TiDB 里叫 Region。Region 是一段连续 Key 范围的数据，默认约 96MB，就像仓库里统一规格的周转箱。为什么要用箱子？因为整仓库找一件食材太慢，按编号段分区后，找食材只要先定位到箱子，再在箱子内翻找。更重要的是，箱子是数据调度和复制的基本单位：每个箱子在三个不同的仓库里各存一份，某间仓库失火，另外两间还能供货。

TiKV 的 Key 并不是简单的业务主键，它在内部会做一层编码，把表 ID、行 ID 等信息拼装进 Key，让同一张表的数据在物理上连续存放，扫描时不用跨箱子乱翻。

有了箱子，有了编号，还缺一个关键角色：谁来记下每个箱子放在哪个仓库的哪个货架？这个角色，就是 PD。

PD调度中心

连锁集团的运营经理老周，手上有三样宝贝：一本总台账、一部对讲机、一只盖章机。总台账记着每个箱子（Region）目前在哪个仓库、哪一排货架；对讲机让他每天定时和每个仓库通话，确认“一切正常”；盖章机则是给每笔跨仓业务盖一个统一的时间章，保证所有仓库按同一个时间线记账。

在 TiDB 中，老周就是 PD（Placement Driver，调度中心）。PD 维护的路由元数据，是客户端和 TiDB 节点找到数据的导航地图。TiKV 节点会通过心跳持续向 PD 汇报状态：我活着、我还有多少箱子、我负载多高。一旦某节点心跳超时，PD 立刻判定节点失联，启动副本补足流程。PD 还像一位精明的调度员，发现某台 TiKV 的 Region 特别多、成为热点时，就把一部分箱子搬到空闲节点，让整个集群的负载像水面一样平。

怎么衡量“均匀”？PD 用一个平方和公式作为不均衡度的度量：每个节点 Region 数量的平方加起来，值越小越均衡。这种度量让“大的更大”被放大，从而逼着调度器优先处理最忙的节点。

老周的台账、对讲机和盖章机，让整个集群始终处于“有人管”的状态。但你可能好奇：台账上写着一个箱子有三个副本，这三个副本之间是怎么保持一致的呢？这就是 Region 与 Raft 协议的故事。

Region与Raft

三兄弟合伙开仓库，最怕的就是账目对不上。老周定的规矩是：每一箱食材入库时，必须至少两个兄弟在入库单上签字画押，这箱货才算正式入库；如果三个兄弟都签了，那最好，但缺一个也不耽误收活。签字画押的过程还要写进一本只追加、不修改的流水账本里，方便日后对账。这套制度，就是著名的 Raft 一致性协议。

Region 的每个副本分布在不同的 TiKV 节点上，其中一个被选为 Leader（主副本），负责接收读写请求；另外两个是 Follower（从副本），负责同步日志。当业务要写一条数据时，Leader 把日志广播给 Follower，只要收到多数派（三个里两个）的确认，就可以向客户端返回成功。这样即使一个 Follower 节点宕机，集群依然能正常写入，这就是高可用的底气。

更妙的是，Region 的大小不是写死的。数据越写越多，箱子装满了（超过约 96MB），Region 会自动分裂成两个，像细胞分裂一样；反过来，如果删除数据导致箱子太瘪，相邻 Region 又会合并。PD 正是靠着这套分裂与合并机制，让数据分布始终保持在健康状态。

三兄弟的账本制度，让每一箱食材都有据可查、有错可纠。但面馆越来越大，老周发现了一个新问题：老板每天要的“经营报表”越来越多，可报表查询要是翻流水账，前台就没法做生意了。于是，集团专门成立了一个分析师团队。

TiFlash列存

分析师团队的办公室里，没有锅碗瓢盆，只有一排排特制的大账本。普通仓库的流水账（行存）是按“时间逐笔”记录的，查某一天的交易很快；分析师的账本（列存）则是按“食材名称”整列记录的——“番茄”这一列记着全年每天用了多少斤。老板问“今年番茄用了多少”，分析师扫一眼那一列就算完了，而普通仓库得把整本流水翻个遍。

这排特制账本，就是 TiFlash。TiFlash 是 TiDB 家族里的列存引擎，专门服务分析型查询（OLAP）。它不参与前台收银的主链路，而是以 Raft Learner（学习副本）的身份悄悄旁听每一笔账目，异步复制 TiKV 中的数据。Learner 不参与投票，因此它的同步完全不影响前台交易性能——分析师抄账本归抄账本，收银台该多快还是多快。

TiFlash 就位后，TiDB 就成了一家“既做快餐又出报表”的两栖企业，这就是 HTAP（混合事务与分析处理）。行存服务高频交易，列存服务复杂分析，两边数据天然一致，省去了传统架构里“交易库到分析库的 ETL 搬运”，分析结果实时性大幅提升。对比一下全表扫描的代价，列存的优势一目了然：

分析师团队就位后，连锁集团的“营业”与“经营”两条线互相独立又彼此印证。现在，让我们从头到尾走一遍一笔真实的订单，看看所有角色如何串成一条流水线。

核心流程

一位顾客走进面馆，喊了一声：“来一碗牛肉面，多加香菜！”接下来发生的事，就是 TiDB 的一次完整写入流程。点单员（TiDB 节点）接到 SQL，先解析语义，然后找老周（PD）查台账：牛肉面的食材记录在哪个 Region、主副本在哪个仓库？老周秒回路由信息。点单员直奔目标 TiKV 节点，主副本（Leader）把这条记录写进日志，同步给两个从副本，收到多数派点头后，一份热腾腾的“写入成功”就端给了顾客。

整个过程看似简单，背后却有一项关键保障：分布式事务。面馆做的是“牛肉面套餐”，面条和牛肉必须一起上桌，不能只成功一半。TiDB 采用两阶段提交（2PC）：先让所有相关 Region 的 Leader 把写入操作“预备”好，等全部确认后，再统一“提交”生效。任何一步失败，整笔订单回滚，就像后厨发现牛肉不够，整份套餐就不出餐，绝不上半碗面。

这套流水线同样支持弹性运维。想扩容，新加一台 TiKV，PD 会自动搬一批 Region 过去；某台 TiKV 宕机，PD 心跳超时后，其他副本立刻补位成为新 Leader，业务在秒级内恢复。所有操作对前台顾客无感——他们只觉得这家店“永远在线、从不打烊”。

从接单到上菜，整套流水线环环相扣。最后，我们退后一步，看看这家“数据库连锁集团”在整个行业里到底值多少钱。

架构价值

当初的小面馆，如今成了遍布全国的连锁集团。它的成功密码可以总结为四句话：不怕单店倒闭（高可用）、账本从不扯皮（强一致）、分店想开就开（线性扩展）、老顾客无缝迁移（生态兼容）。这四点，正是 TiDB 作为 NewSQL 代表在工业界站稳脚跟的根基。

高可用来自多副本与 Raft：任意一台机器宕机，数据不丢、服务不停。强一致来自 Raft 日志复制与分布式事务：多副本不会出现“各说各话”的脏读。线性扩展来自计算存储分离与 Region 自动调度：加机器就能同时加容量和性能。生态兼容来自 MySQL 协议：应用层 ORM、运维工具、监控体系几乎零改造接入，企业迁移成本极低。

衡量这套体系“有多可靠”，有一个朴素而有力的公式。系统的可用性取决于平均无故障时间（MTBF）和平均修复时间（MTTR）：出故障不可怕，怕的是修得慢；自动化故障转移正是把 MTTR 从小时级压到秒级的关键。

小同的面馆故事讲完了：前厅接单、仓库存货、经理调度、分析师算账，各司其职又浑然一体。TiDB 之所以能成为 NewSQL 的标杆，正是因为它把分布式系统的复杂藏在了熟悉的 MySQL 面孔之下。理解了这套整体架构，你就拿到了走进分布式数据库世界的第一把钥匙。

AI 应用场景

Python 演示

"""mini_tidb.py：简化版TiDB架构模拟器"""REGION_MAX = 50  # 每个Region最多容纳50条记录  class Region:    """一个Region = 一段连续Key范围的数据分片"""     def __init__(self, rid, start, end):        self.rid = rid        self.start = start        self.end = end        self.data = {}     def in_range(self, key):        return self.start <= key < self.end     def put(self, key, value):        self.data[key] = value        return len(self.data) >= REGION_MAX  # 超容量返回True  class TiKVNode:    """存储节点，对应一个TiKV实例"""     def __init__(self, node_id):        self.node_id = node_id        self.regions = []     def count(self):        return len(self.regions)  class PD:    """调度中心：维护路由，执行分裂与负载均衡"""     def __init__(self, nodes):        self.nodes = nodes        self.route = {}  # rid -> node_id     def assign(self, region):        """把Region放到当前Region最少的节点并登记路由"""        node = min(self.nodes, key=lambda n: n.count())        node.regions.append(region)        self.route[region.rid] = node.node_id        return node     def route_to(self, key):        """根据Key找到对应Region和所在节点"""        for node in self.nodes:            for r in node.regions:                if r.in_range(key):                    return r, node        raise KeyError("no region for key: %s" % key)     def split(self, r):        """Region分裂：一半数据留给原Region，一半交给新Region"""        keys = sorted(r.data)        mid = len(keys) // 2        split_key = keys[mid]        new_r = Region(len(self.route) + 1, split_key, r.end)        r.end = split_key        for k in keys[mid:]:            new_r.data[k] = r.data.pop(k)        target = self.assign(new_r)        print("[分裂] Region%d -> Region%d, 新Region放到TiKV%d"              % (r.rid, new_r.rid, target.node_id))     def balance(self):        """把Region最多的节点上的Region迁到最少的节点"""        src = max(self.nodes, key=lambda n: n.count())        dst = min(self.nodes, key=lambda n: n.count())        if src.count() - dst.count() >= 2:            moved = src.regions.pop()            dst.regions.append(moved)            self.route[moved.rid] = dst.node_id            print("[调度] Region%d从TiKV%d迁到TiKV%d"                  % (moved.rid, src.node_id, dst.node_id))  def main():    nodes = [TiKVNode(1), TiKVNode(2), TiKVNode(3)]    pd = PD(nodes)    pd.assign(Region(1, 0, 10000))     for key in range(200):        r, node = pd.route_to(key)        need_split = r.put(key, "value_%d" % key)        if need_split:            pd.split(r)            if key % 40 == 0:                pd.balance()     print("最终Region分布:")    for n in nodes:        rids = [r.rid for r in n.regions]        print("TiKV%d: %d个Region %s" % (n.node_id, n.count(), rids))  if __name__ == "__main__":    main()

1. class PD模拟调度中心，负责路由登记、分裂决策和迁移调度，对应真实 TiDB 中的 PD 组件。
2. pd.route_to(key)根据 Key 范围找到对应 Region 和所在节点，模拟 PD 路由查找。
3. r.put(key, "value_%d" % key)写入数据并判断 Region 是否超过容量上限，超限时返回 True 触发分裂。
4. pd.split(r)把 Region 的 Key 从中间一分为二，一半数据留给旧 Region，一半归新 Region。
5. pd.balance()比较各节点 Region 数量，把最忙节点的 Region 迁到最闲节点，模拟 PD 负载均衡。
6. pd.assign(new_r)把新建 Region 放到当前 Region 最少的节点，模拟“新箱子放空仓库”的调度策略。

常见误区

面试题