从 MySQL DBA 到分布式数据库TiDB 入门理解

目标读者：熟悉 MySQL、想了解分布式数据库的运维和开发同学

一、为什么需要了解 TiDB？

作为运维 DBA，我们习惯了 MySQL 的主从架构：一台主库扛写，几台从库扛读，数据量大了就上分库分表，业务复杂了就上中间件。这套方案用了十几年，稳定可靠，但也有几个绕不开的痛点：

TiDB 的设计初衷就是解决这些问题。它是一款开源的分布式 SQL 数据库，兼容 MySQL 协议，却拥有云原生架构的弹性扩缩容能力。理解它的架构，能帮我们打开”分布式数据库”这扇大门。

二、TiDB 整体架构：一个”公司”的比喻

TiDB 的架构采用了计算与存储分离的设计，整个集群就像一家运转良好的公司，各层职责清晰：

┌─────────────────────────────────────────┐│           客户端 (MySQL 协议)            │└─────────────────────────────────────────┘                    │┌─────────────────────────────────────────┐│  TiDB Server 层  │  TiDB Server 层      │  ← 销售部（无状态，可随意增减）│  (SQL 计算层)    │  (SQL 计算层)        │└─────────────────────────────────────────┘                    │┌─────────────────────────────────────────┐│      PD (Placement Driver)              │  ← 调度中心（大脑，只有 3/5 个节点）│      元数据管理 + 全局时钟 + 调度         │└─────────────────────────────────────────┘                    │┌─────────────────────────────────────────┐│  TiKV 节点  │  TiKV 节点  │  TiKV 节点  │  ← 仓库（存数据，多副本）│  (行存储)   │  (行存储)   │  (行存储)   │└─────────────────────────────────────────┘                    │┌─────────────────────────────────────────┐│  TiFlash 节点 │ TiFlash 节点 (可选)      │  ← 分析部（列存储，实时同步）│  (列存储)     │                         │└─────────────────────────────────────────┘

1. TiDB Server —— “销售部”（无状态计算层）

• 职责：接收客户端的 SQL 请求，做词法/语法解析、查询优化，生成执行计划，然后把实际的读写请求发给存储层。

• 关键特性：无状态。节点本身不存数据，就像销售部不囤货，只负责接单和协调。

• 运维意义：流量涨了？直接加几台 TiDB Server，前面挂个负载均衡（TiProxy / LVS / HAProxy），扩容对业务完全透明。不需要像 MySQL 那样做数据迁移。

2. PD —— “调度中心”（集群大脑）

• 职责：

– 存储集群拓扑和元数据（哪个 Region 在哪些节点上）

– 分配全局单调递增的时间戳（TSO，Timestamp Oracle），这是分布式事务的”生命线”

– 监控数据分布，自动做负载均衡和故障转移

• 关键特性：PD 本身通过 etcd 实现高可用，通常部署 3 或 5 个节点，容忍少数节点故障。

• 运维意义：PD 挂了集群就停摆，所以部署时一定要保证奇数节点、跨机架/跨可用区。

3. TiKV —— “仓库”（分布式存储层）

• 职责：真正存数据的地方。TiKV 是一个分布式事务型 KV 存储，基于 RocksDB 构建，数据按 Key-Value 形式存储。

• 关键特性：

– Region：数据被切分成一个个约 96MB（默认）的连续 Key 范围，称为 Region。Region 是 TiDB 调度的最小单元。

– Raft 协议：每个 Region 默认有 3 个副本，通过 Raft 实现强一致性。写入必须落盘到多数派（2/3）才能提交。

– 自动分裂与合并：数据量大了 Region 自动分裂，小了自动合并，PD 负责把 Region 在节点间调度均衡。

• 运维意义：你不需要像分库分表那样设计 Shard Key，TiDB 自动帮你分片。节点挂了？只要多数派存活，数据不丢、服务不停。

4. TiFlash —— “分析部”（列式存储，可选）

• 职责：通过 Raft Learner 协议实时从 TiKV 同步数据，以列存格式存储，专门服务 OLAP 分析查询。

• 关键特性：

– 数据同步是异步的，但不阻塞 TiKV 的写入

– TiDB 优化器会自动判断：点查、小范围扫描走 TiKV；聚合、大表扫描走 TiFlash

– 支持 MPP（大规模并行处理），多节点协同计算

• 运维意义：一套集群同时搞定 OLTP 和 OLAP，这就是 HTAP（混合事务分析处理）。不再需要凌晨抽数到 Hive/ClickHouse，实时报表直接查 TiDB。

三、分布式数据库的核心概念：DBA 必须懂

从单机 MySQL 切换到 TiDB，最大的思维转变是：数据不再存在一台机器上，一致性、事务、时钟都需要分布式协议来保证。

1. Region：数据的”集装箱”

想象你要搬家，MySQL 是把所有东西塞进一个大卡车（单机），TiDB 是把东西分成很多标准集装箱（Region），每个集装箱有编号（Key Range），由不同的卡车（TiKV 节点）运输。

• 每个 Region 默认 96MB，超过阈值自动分裂

• 每个 Region 有 Leader 和 Follower，Leader 负责读写，Follower 同步数据

• PD 根据负载和磁盘容量，把 Region 在节点间搬来搬去（Balance）

运维提示：热点问题往往是一个 Region 被集中访问。TiDB 提供了 SPLIT TABLE、SHARD_ROW_ID_BITS 等手段打散热点，类似 MySQL 里处理自增 ID 热点，但粒度更细。

2. Raft：分布式系统的”民主投票”

Raft 是一种共识算法，解决的是”多个节点如何对一件事达成一致”的问题。

• Leader 选举：每个 Region 的副本之间会选出一个 Leader，负责处理写请求

• 日志复制：Leader 先把写入记到日志，然后同步给 Follower，多数派确认后才提交

• 故障恢复：Leader 挂了，Follower 之间重新选举，通常几秒内恢复

类比：公司做一个重大决策，不是老板一个人说了算，而是要董事会多数成员签字同意。Raft 就是这个”签字”机制。

3. 分布式事务：Percolator 模型

TiDB 的分布式事务基于 Google Percolator 模型，核心是两阶段提交（2PC）+ TSO：

1. 获取 Start TS：从事务开始时，向 PD 要一个全局时间戳

2. 预写（Prewrite）：在 Primary Key 和 Secondary Keys 上写入锁和数据

3. 提交（Commit）：向 Primary Key 发起提交，成功后清理锁

关键点：TSO 是 PD 分配的，保证全局唯一且递增，这是实现 SI（Snapshot Isolation，快照隔离）的基础。

运维提示：分布式事务的延迟天然高于单机事务（需要跨节点协调）。长事务、大事务容易成为瓶颈，应用层应尽量控制事务大小。

4. HTAP：一份数据，两种用法

传统架构：

MySQL(OLTP) → Canal → Kafka → Flink → Hive/ClickHouse(OLAP)

链路长、延迟高、维护复杂。

TiDB HTAP：

应用 → TiDB Server → [TiKV(行存) / TiFlash(列存)]

同一份数据，TiKV 用行存服务高频短事务，TiFlash 用列存服务分析型查询，查询优化器自动选择最优路径。

四、TiDB vs MySQL：DBA 视角的对比