一、 TiDB 的分布式架构的核心理解 传统关系型数据库在单机时代所向披靡，但当数据量和并发量增长到一定规模时，垂直扩展的物理极限便成为瓶颈。分库分表虽然可以缓解压力，却带来了应用改造、跨分片事务、运维复杂度等一系列新问题。TiDB 的出现，正是为了用分布式架构在不牺牲 SQL 能力和事务一致性的前提下，实现真正的水平扩展。 理解 TiDB 的架构原理，核心在于把握一个设计哲学：分层解耦。TiDB 将数据库系统拆分为计算层、调度层和存储层，每一层都可以独立扩展、独立演进。这种“计算与存储分离”的架构思想，是贯穿 TiDB 全部技术设计的底层逻辑。
二、整体架构：四层组件协同 TiDB 集群由四个核心组件构成，它们各司其职，通过高效的协作形成一个完整的分布式数据库系统。 TiDB Server（计算层） 是整个系统的 SQL 入口。它对外暴露 MySQL 协议，应用程序可以像连接 MySQL 一样连接 TiDB，无需修改代码。TiDB Server 本身不存储任何数据，它的职责是接收 SQL 请求、进行解析和优化、生成分布式执行计划，然后将实际的数据读写请求转发给底层的存储节点。由于无状态，可以部署多个 TiDB Server 实例，通过负载均衡组件分摊客户端连接，实现计算能力的线性扩展。 PD Server（调度层） 是集群的“大脑”。它管理着整个集群的元信息——每个 TiKV 节点上存了哪些数据、每个 Region 的副本分布在哪里。同时，PD 还承担着全局授时服务（TSO）的职责，为分布式事务提供全局单调递增的时间戳，这是实现跨节点事务一致性的基石。PD 还会持续监控各存储节点的负载情况，当发现热点或数据分布不均时，自动发起 Region 调度，将负载从过热的节点迁移到空闲节点。 TiKV Server（行存引擎） 是数据的持久化层，一个分布式的、支持事务的 Key-Value 存储引擎。TiDB 中的所有业务数据最终都存储在 TiKV 中。TiKV 采用行式存储，针对高并发、低延迟的事务型读写场景做了深度优化。 TiFlash Server（列存引擎） 是 TiKV 的列存扩展。它将数据以列式格式存储，专门服务于分析型查询。TiFlash 的数据通过 Raft 协议从 TiKV 实时同步，保证了与行存数据的一致性，同时又不参与 TiKV 的写入投票，因此分析查询不会影响在线事务的性能。
三、存储层核心机制：Region、RocksDB 与 Raft TiKV 的存储设计可以概括为“分而治之、多副本保障”。理解这三个关键词，就理解了 TiKV 的核心。 数据分片：Region。 TiKV 将整个 Key-Value 空间按照 key 的范围切分成若干个大致相等的片段，每个片段称为一个 Region。Region 是数据迁移和调度的基本单元。集群初始化时只有一个覆盖全部 key 空间的 Region，随着数据写入不断分裂，当某个 Region 的大小超过阈值（默认 144MB）时，TiKV 会将其一分为二；而当大量删除导致 Region 过小时，相邻的小 Region 又会合并。 本地存储：RocksDB。 每个 TiKV 节点上部署有两个独立的 RocksDB 实例：一个存储实际的 Region 数据，另一个存储 Raft 日志。这种分离设计的原因是，Raft 日志是严格的顺序写入，而 Region 数据则涉及随机读写，将两者分开可以避免 I/O 互相干扰，同时同一节点上多个 Region 的写入可以在同一个 RocksDB 实例中合并为一次 I/O，提升吞吐。 一致性保障：Raft 协议。 每个 Region 有多个副本（默认 3 个），分布在不同节点上，构成一个 Raft Group。其中一个是 Leader，负责处理所有读写请求；其余是 Follower，通过 Raft 协议从 Leader 同步数据。任何写入必须在多数副本确认后才算成功，这意味着即使一个节点宕机，数据也不会丢失，系统仍可正常读写。 调度机制。 PD 在后台持续扫描所有 Region 的状态。当需要将一个副本从节点 A 迁移到节点 B 时，PD 先在 B 上创建一个 Learner 副本（只同步数据、不参与投票），待 Learner 追上 Leader 的进度后，将其提升为 Follower，再移除 A 上的旧 Follower，完成一次平滑的副本迁移。
四、分布式事务：Percolator 模型与 MVCC 分布式事务是 TiDB 最具技术挑战性的部分。TiDB 的事务实现基于 Google 的 Percolator 模型，本质上是一种优化的两阶段提交（2PC），配合 MVCC（多版本并发控制） 实现快照隔离级别。 Percolator 的核心思想是：在分布式 KV 存储之上构建事务能力，而不依赖中心化的协调节点。一个事务的提交分为两个阶段：第一阶段，在所有涉及的 key 上写入锁和指向主锁的指针；第二阶段，提交主锁，然后异步清理其余锁。如果事务进行中发生故障，其他事务在遇到锁时可以通过主锁的状态判断是否需要回滚或等待。 MVCC 则为每个数据版本附加时间戳，读取时根据事务的开始时间戳选择可见的数据版本。这使得读操作不会阻塞写操作，写操作也不会阻塞读操作，在高并发场景下能保持良好的吞吐量。 TiDB 同时支持乐观事务和悲观事务两种模式。乐观模式适合冲突较少的场景，提交时才检测冲突，延迟更低；悲观模式适合高冲突场景，在写入前就加锁，避免事务提交时才发现冲突而回滚。
五、HTAP 双引擎：TiKV 与 TiFlash 的协同 TiDB 最具创新性的架构设计，在于它用一套系统同时支撑了 OLTP 和 OLAP 两种截然不同的负载，也就是 HTAP（混合事务/分析处理）。
传统方案中，企业需要维护两套系统：一套 OLTP 数据库处理在线交易，一套 OLAP 数据仓库做分析。两者之间通过 ETL 管道同步数据，存在延迟高、维护复杂、数据不一致等问题。TiDB 的方案是在同一个数据库内同时提供行存引擎（TiKV）和列存引擎（TiFlash），分析查询自动路由到 TiFlash，交易查询走 TiKV，两者物理隔离、互不干扰。 数据同步机制。 TiFlash 通过 Raft Learner 角色从 TiKV 异步复制数据。Learner 是 Raft 协议中的一种特殊副本：它接收 Leader 同步过来的日志并应用到本地，但不参与投票，不影响 TiKV 的写入提交过程。这意味着即使 TiFlash 节点宕机或网络延迟，也不会对 TiKV 的事务处理产生任何影响。 一致性读取。 TiFlash 虽然采用异步复制，但在读取时通过 Raft 的 ReadIndex 机制获取当前已提交的最新日志位置，然后等待本地应用进度追上该位置，再执行查询。这样，TiFlash 对外提供的是与 TiKV 一致的 Snapshot Isolation 隔离级别，用户看到的数据始终是一致的。 MPP 执行框架。 TiFlash 自 5.0 版本起引入了 MPP（大规模并行处理）执行模式。在 MPP 模式下，一条复杂的分析查询会被切分为多个查询片段（query fragment），每个片段在持有相关数据的 TiFlash 节点上并行执行，节点之间通过 ExchangeSender 算子进行数据交换。这种“数据在哪，计算就在哪”的模式，避免了大量数据在节点间搬运，显著加速了分析查询。
六、计算下推：让计算靠近数据 TiDB 架构中一个贯穿始终的优化原则是计算下推。TiDB Server 在生成执行计划时，会将过滤条件、聚合函数等算子尽可能下推到存储层执行。比如一个 SELECT ... WHERE age > 30 的查询，TiDB 不会把全表数据拉到计算层再过滤，而是将 age > 30 这个谓词下推给 TiKV 的 Coprocessor，在数据所在的节点上完成过滤，只把符合条件的行返回。
这种设计的意义在于：分布式系统中，网络传输往往是最昂贵的操作。通过将计算下沉到数据所在的节点，可以大幅减少跨网络的传输量，从而提升整体查询性能。
七、总结 TiDB 架构的本质，是用分层解耦和多副本共识两大支柱，构建一个既能像 MySQL 一样处理在线事务，又能像数据仓库一样执行实时分析的分布式数据库。 TiDB Server 负责计算，无状态、可弹性扩展； PD 负责调度，掌握全局信息、驱动数据均衡； TiKV 负责行存，以 Region 为单元分片，以 Raft 协议保障多副本一致性和高可用； TiFlash 负责列存，通过 Raft Learner 异步同步、MPP 并行加速，在不影响事务性能的前提下提供实时分析能力。 理解这套架构的关键，不在于记住每个组件的功能列表，而在于体会每一层设计背后的取舍逻辑：为什么计算要无状态（为了弹性）、为什么副本要多数确认（为了容错）、为什么列存要异步同步（为了隔离）、为什么计算要下推（为了减少网络开销）。这些取舍共同构成了 TiDB 作为新一代分布式数据库的技术底座。