深入解析 TiDB 分布式架构：三大核心组件与底层运行原理

TiDB 是一款兼容 MySQL 协议的分布式关系型数据库整体架构由PD 集群、KV 集群、TiDB Server无状态节点三大核心模块组成。三者分工明确、协同工作依托 Raft 共识算法实现高可用、强一致性与弹性扩缩容下面从组件功能、实操演示、底层算法、架构优势等维度全面拆解。一、PDPlacement Driver集群集群全局管控核心PD 是 TiDB 的 “大脑”主要负责存储、管理数据库运行所需的系统级元数据统筹整个集群的调度、路由与全局管控。在架构交互上PD 会与上层 SQL 层集群交互时间戳、数据位置信息同时和下层 KV 集群同步元数据核心能力分为三部分1. TSOTimestamp Oracle时间戳授时器TSO 是实现分布式强一致性事务的核心组件可直译为时间戳授时器。TiDB 支持强一致性分布式事务必须精准判定所有操作的先后顺序。即便数据库无任何数据变更PD 也会持续生成单调递增的时间戳。当服务端发起事务、执行数据修改时都需要向 PD 申请最新 TSO。依靠全局统一的时间戳分布式集群会形成有序时间流以此支撑多版本并发控制MVCC等事务核心能力。补充说明此处的 Oracle 仅代表 “权威授时节点”和商用 Oracle 数据库无任何关联。2. Data Location 数据位置路由TiDB 服务端执行 SQL 查询时并不清楚数据的实际存储节点该路由工作由 PD 全权负责。TiDB 会将数据表的数据行Row拆分存储在一个个Region数据分片中PD 全局维护映射关系某条数据归属哪个 Region、该 Region 部署在哪台存储节点。简单来说PD 就是整个集群的数据路由中心Region 相关细节后文会详细介绍。3. Metadata 集群元数据管理PD 统一管理集群各类管理型元数据。典型场景在 TiDB 中新建数据表时表的全局唯一编号由 PD 统一分配。除此之外数据库对象标识、集群配置等管理类信息均由 PD 维护。综上PD 集群承载 TiDB 所有系统级能力与管控数据而用户创建的表、索引等业务数据则全部存储在 KV 集群中。二、KV 集群分布式数据存储引擎KV 集群本质是一套分布式键值Key-Value数据库属于标准 NoSQL 组件原生提供 KV 读写接口也是 TiDB 真正落地业务数据的存储层。上层 SQL 层会将用户输入的 SQL 语句转译为底层 KV 操作再调用 KV 集群接口完成数据存取。KV 集群本身无法解析 SQL 语法仅识别键值对格式数据所有读写操作都基于 Key-Value 实现。本地环境实操演示为直观理解 KV 集群的交互逻辑我们在单机搭建测试环境进行演示集群部署说明本次演示将 PD、KV 部署在同一台机器方便调试生产环境严禁混部需将两类组件拆分部署至不同服务器保障资源隔离与高可用。目前集群所有服务已正常启动。客户端使用提醒测试使用的 Python 版 KV 客户端模块仅适用于演示场景功能与稳定性不达标禁止在生产环境使用。集群连接调用连接函数时传入任意一个 PD 节点的访问地址Endpoint即可建立连接多 PD 节点能力对等。数据读写KV 集群仅接收字节流bytes格式数据。写入时构造 Key-Value 键值对读取时通过指定 Key 即可查询对应 Value全程仅基于键值对交互不识别 SQL。有状态集群与 Raft 容错算法PD 集群与 KV 集群都属于Stateful有状态集群节点会在本地磁盘持久化数据。很多人会产生疑问如果节点宕机、甚至彻底损坏数据是否会丢失答案是否定的核心保障就是Raft 共识算法。Raft 是主流分布式共识算法作用是保证多副本数据的完整性与一致性核心遵循多数派原则。1. Raft 在 PD 集群中的应用生产环境 PD 一般部署 3 个节点数据默认保存 3 份副本并分散至所有 PD 节点。角色划分同一时刻集群内仅有一个 Leader 主节点其余为 Follower 从节点写入规则数据成功写入超过半数节点3 节点集群至少写入 2 个即判定写入完成故障自愈单个从节点宕机不影响服务若 Leader 节点故障剩余存活节点会自动重新选举新 Leader集群无感知切换。2. Raft 在 KV 集群中的应用KV 集群同样使用 Raft 算法但共识单元不同PD 以整节点为单位达成共识KV 则以Region数据分片为最小共识单元。分片规则TiDB 默认单个 Region 大小为 96MB每个 Region 配置 3 份副本分散在不同 KV 节点上角色机制单个 Region 内部同样区分 Leader 与 Follower遵循 Raft 多数派原则灵活配置KV 集群可包含大量节点但单个 Region 仅占用 3 台节点存放副本副本数量支持自定义调整。分片数量估算以 100TB 业务数据为例按照默认 96MB/Region 计算分片总量单位换算\(100\ \text{TB} 100 \times 1024 \times 1024 104857600\ \text{MB}\)Region 总数\(104857600 \div 96 \approx 1092267\)由此可得100TB 数据按照默认规则拆分约产生109 万个 Region 分片。海量轻量化分片也是 TiDB 实现数据均衡调度、分布式存储的基础。三、TiDB Server无状态 SQL 接入层TiDB Server 属于Stateless无状态节点也是用户访问数据库的入口。该节点不存储任何系统数据与业务数据核心职责是对外提供兼容 MySQL 的访问接口。用户提交的 SQL 语句全部由 TiDB Server 接收完成语法解析、生成执行计划并将 SQL 逻辑转译为底层可执行指令下发给 KV 存储层完成数据读写。四、TiDB 整体架构优势与扩缩容能力整套 TiDB 由「有状态 PDKV 集群」「无状态 TiDB Server」组成架构不依赖共享存储全部使用本地磁盘Local Storage所有组件均支持横向线性扩缩容可根据业务压力灵活调整资源特性类似微服务架构。1. 各组件扩缩容规则PD 集群负载过高时新增节点即可。受 Raft 多数派协议约束节点总数建议设置为奇数保证选举与数据一致性正常运行。KV 集群当存储容量不足、读写算力吃紧时新增 KV 节点即可分担压力数据会自动完成分片迁移与均衡Region 副本数同样建议配置为奇数。TiDB Server作为计算接入层若 SQL 请求量大、响应变慢直接增加节点业务低峰、资源闲置时可下线节点释放资源。2. 架构设计核心特点TiDB 整套架构的设计理念处处体现负载均衡思想。我们可以将它理解为一台强化型负载均衡器在实现分布式数据存储、强一致性事务处理的基础上原生兼容 MySQL 协议兼顾分布式数据库的高性能、高可用与传统关系型数据库的使用习惯这也是 TiDB 最核心的设计亮点。总结PD 集群全局管控中心负责授时、路由、元数据管理KV 集群底层存储引擎基于键值对存储业务数据依托 Region 分片 Raft 算法实现高可用TiDB ServerSQL 接入网关无状态设计负责语句解析与请求转发。三大组件各司其职、配合默契结合本地存储、线性扩缩容、Raft 强一致性等特性让 TiDB 成为适配海量数据、高并发场景的主流分布式数据库。官网资料学习整理原视频地址如下TIDB架构与特点-01TIDB整体架构https://learn.pingkai.cn/learner/player/630005;id630005;classroomId960002;rcoId1080432;courseDetailId600003;learnerAttemptId1780236619005