Marico's space

深入理解 TiDB 架构：如何用 SQL 搞定分布式数据库 | TiDB 架构全解析

算法解析 2026-04-26 21:08:02 17

【译者前言】说到分布式数据库，很多人第一反应是 NoSQL——觉得 SQL 搞不定大规模扩展，或者觉得要用就得在事务一致性上妥协。TiDB 这个项目挺有意思，它走的是另一条路：让 SQL 重新变得能打，同时又不丢掉传统关系型数据库那些我们熟悉的好东西。这篇文章把 TiDB 的架构拆得比较透，核心设计思路讲得清楚，适合想了解 NewSQL 这条路怎么走的朋友。

本文较长，先上个概览图镇楼。TiDB 整个集群由三类核心组件构成：TiDB Server（计算层）、TiKV（存储层）、PD（调度层），外加可选的 TiFlash（分析加速器）。理解这四块的分工，就理解了大半。

为什么 TiDB 值得关注？

现在的应用动不动就要求 7×24 小时在线，要扛住突发的流量洪峰，要处理海量数据。传统单机数据库在这种压力下，往往只能靠升级硬件或者手动分库分表来苟延残喘，运维成本高不说，迁移还特别痛苦。

TiDB 的定位是 NewSQL——既保留了 SQL 的事务一致性（ACID）和熟悉接口，又具备 NoSQL 那样的水平扩展能力。它跟 MySQL 兼容，所以现有工具、驱动、SQL 语句基本能直接迁移过来，对团队来说学习成本很低。

简单说，它就是为云原生时代重新设计的一款分布式 SQL 数据库。

前置知识：需要准备什么？

上手 TiDB 不需要成为分布式系统专家，但有几样东西会帮助你理解得更深：

SQL 基础：会用 SELECT、INSERT、UPDATE 等基本语句就行。TiDB 兼容 MySQL 协议，你的经验完全可以迁移过来。
分布式系统概念（可选但推荐）：共识协议、分区、容错这些词如果眼熟，会有助于理解 TiDB 的内部机制。当然，现学也不是不行。
Kubernetes：虽然 TiDB 可以跑在物理机上，但它天然适合容器化部署，在 K8s 上管理起来更顺手。
Linux 基础：大部分运维操作还是靠命令行。

核心架构：存储计算分离

TiDB 最重要的设计决策是存储与计算分离。传统数据库里，计算引擎和存储引擎是绑在一起的，扩展起来要么一起扩要么忍痛割爱。TiDB 把它们拆开，各自独立扩展，按需调配，灵活度和资源利用率都高很多。

来看几个关键组件：

1. TiDB Server——集群的大脑

TiDB Server 负责所有 SQL 处理，是无状态的查询层，可以简单地理解为"乐队的指挥"。

SQL 解析与优化器：收到 SQL 后先解析，再生成最优执行计划——重写查询、选索引、决定 join 顺序，都在这步完成。
事务协调器：这是 TiDB 保证 ACID 的关键。即使在分布式环境下，它也能确保原子性、一致性、隔离性、持久性。底层用的是 Google 的 Percolator 事务模型。
分布式执行引擎：大查询会被拆成多个可并行的子任务，分配到不同节点上跑，甚至可以下推到存储层。
连接网关：负责接收应用发来的连接，作为所有 SQL 请求的入口。

连接示例（Python）：

import mysql.connector

config = {
    'user': 'root',
    'host': '127.0.0.1',
    'port': 4000,
    'database': 'test'
}

try:
    conn = mysql.connector.connect(**config)
    cursor = conn.cursor()

    cursor.execute("SELECT VERSION()")
    version = cursor.fetchone()
    print(f"TiDB 版本：{version[0]}")

    cursor.execute("CREATE TABLE IF NOT EXISTS users (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100))")
    print("users 表检查/创建完成")

    conn.commit()
exceptmysql.connector.Error as err:
    print(f"错误：{err}")
finally:
    if 'cursor' in locals() and cursor:
        cursor.close()
    if 'conn' in locals() and conn:
        conn.close()

2. TiKV——数据的家，分布式键值存储

TiKV 是真正存数据的地方，一个分布式、支持事务的键值（Key-Value）存储引擎。每个 TiKV 节点上都躺着数据分片，我们叫它 Region（类似于分片/shard 的概念）。

数据分片与副本：每个 Region 会在多个 TiKV 节点上自动复制副本，高可用和容错都靠这个机制。就算某个节点挂了，数据在其他副本还是安全的。
Raft 共识算法：为了保证副本间的一致性，TiKV 用了 Raft 共识算法。所有写操作必须获得多数副本确认才算提交，强一致性就是这样来的。
键值存储核心：本质上是个 KV 引擎，但在 TiDB Server 的加持下，可以高效地做范围扫描和复杂查询。
Region 自动管理：数据涨了，Region 会自动分裂；数据缩了，会自动合并。整个集群的负载再平衡也是自动的，不需要人工干预分片策略。

TiDB Server 读写数据时，先判断数据落在哪个 Region，然后直接跟对应 TiKV 节点通信，剩下的事 TiKV 自己搞定。

3. PD（Placement Driver）——调度员兼元数据管家

PD 是整个集群的"幕后军师"，负责全局协调。可以把它想象成空中交通管制员——所有数据的位置和流向都归它管。

元数据管理：记录集群里有哪些 TiDB Server、各 Region 在哪、拓扑结构如何。
Region 调度：决定 Region 应该落在哪些节点上，以及负责分裂、合并、迁移。
Leader 选举：协调 Region 的 Leader 选举——哪个节点是主节点，谁来承担写请求。
负载均衡：持续监控各节点压力，自动把 Region 往压力小的地方挪，避免热点。

4. TiFlash——分析加速器

TiKV 适合 OLTP（事务型）场景，TiFlash 则专为 OLAP（分析型）场景优化，是可选项但强烈推荐。

列式存储：数据按列而非按行存放，对需要扫大量行但只读少数列的分析查询非常友好。
实时同步：TiFlash 从 TiKV 近实时同步数据，跑分析查询时可以拿到最新数据，而不影响交易业务的性能。
PD 协同调度：PD 也会管 TiFlash 副本的分布，确保分析数据均匀且可得。

建表时指定 TiFlash 副本即可启用（具体方式因部署方式不同可能通过 PD 或 tikv-ctl 命令操作）。

优势：为什么选 TiDB？

MySQL 兼容：这条很关键。已有 MySQL 应用的团队平移过来几乎零成本，工具、驱动、SQL 都可以复用。
水平扩展：这是 TiDB 的核心能力。数据量和流量涨了，直接加节点就行，集群会自动重新分布负载，分库分表那些苦差事就此告别。
高可用与容错：数据多副本加上自动 failover，单机甚至整个机房挂了都不带怕的。
强 ACID 事务：不像很多分布式 NoSQL 那样在一致性上打折扣，TiDB 给出的是完整的事务保证。
HTAP（混合事务分析处理）：有了 TiFlash，一套集群同时搞定交易和分析两类需求，不需要额外建数仓和 ETL 流程。
云原生设计：特别适合跑在 Kubernetes 上，部署、运维、扩缩容都可以很优雅。
成本可控：计算和存储独立扩，避免了传统方案里"要么全扩要么都不扩"的尴尬。

局限：哪些场景需要掂量一下？

简单场景的复杂度：如果只是跑个小体量单机应用，分布式带来的额外复杂度可能是过度设计。
成熟度：TiDB 本身迭代很快，但跟 Oracle、PostgreSQL 这种三四十年积累的数据库比，在一些非常细分的特性上可能还有差距。
运维学习曲线：分布式系统跟单机数据库的运维思维很不一样，理解 PD 调度策略和 TiKV Region 管理需要投入精力。
网络延迟：节点间通信必然引入延迟，TiDB 在这方面已经做了很多优化，但还是要心里有数。
资源开销：跑 TiDB Server、TiKV、PD 三个组件，资源消耗比单机数据库要多一些。

核心特性一览

分布式事务（Percolator 模型）：跨节点写入的一致性保证。
自动分片与 Region 管理：数据分布和再平衡全自动，运维压力小。
SQL 防火墙与威胁情报：内置安全防护。
数据加密：支持静态加密和传输加密。
时序表（TST）：针对 IoT 和监控场景做了专门优化。
GC（垃圾回收）：TiKV 里有成熟的空间回收机制。
Spark / Flink 集成：可以接入大数据处理流水线。
监控告警体系：配套比较完整。

写在最后

TiDB 的架构设计确实值得细品。它用存储计算分离的思路，加上合理的组件分工，让团队可以在不需要搞定分库分表的情况下，获得水平扩展能力和高可用保障。对正在经历数据快速增长、或者对数据库扩展性有较高需求的团队来说，TiDB 是值得认真研究的选择。

它不只是一个数据库，更像是一个可以承载下一代数据密集型应用的基础平台。感兴趣的可以搭个集群自己试试，文档生态也比较成熟。