为什么要做计算与存储分离

传统单机数据库的扩展路径是纵向的：换更强的 CPU、加更多内存、上更快的盘。这条路很快会撞到物理上限，而分库分表又把手动切分、跨片事务和数据迁移的复杂度转嫁给了业务方。分布式数据库的核心思路是把这两件事拆开：计算层可以随意加节点，存储层也可以随意加节点，两者独立扩缩容。

以 TiDB 的公开架构为例，计算层由无状态的 TiDB Server 承担 SQL 解析、优化与执行；存储层由 TiKV 负责数据的持久化；PD 作为集群的元信息管理与调度中心。计算层不保存业务数据，因此增加一个 TiDB Server 只需挂到负载均衡之后即可生效。

数据是怎么被切分的

存储层不会把一张表整体放在一台机器上。TiKV 按范围把数据切成若干 Region，每个 Region 是一段连续的键区间，并作为复制与调度的基本单位。Region 达到一定大小后会分裂，多个相邻的小 Region 也可能被合并。

  • Region 是数据分片单位，也是 Raft 复制组单位；
  • 每个 Region 默认维护多个副本，分布在不同节点甚至不同机房；
  • PD 根据节点负载与副本分布情况，自动调度 Region 的 Leader 与副本位置。

这种设计让集群的容量上限不再取决于单机磁盘，而近似取决于节点数量。扩容时新节点加入，PD 会把部分 Region 逐步迁移过去，整个过程不需要停机。

多副本与故障自恢复

写入不会只落一份。每个 Region 的多个副本之间通过 Raft 协议复制日志，只有多数派副本确认写入成功，事务才被认为提交。这带来两个直接收益：单副本故障时数据不丢；副本所在节点宕机时，Raft 会自动在剩余副本中选出新的 Leader，故障转移不需要人工介入。

副本的地理位置可以配置：同城三中心、两地三中心等不同容灾级别，本质上都是通过副本放置策略来调节容灾能力与写入延迟之间的平衡。

落地时需要关注的问题

  • 热点问题：自增主键容易造成写入集中在单一 Region，通常改用打散策略或复合主键；
  • 网络延迟：跨机房副本会拉高写入延迟，需要根据业务容忍度决定副本拓扑；
  • 容量规划：多副本意味着实际存储开销是数据量的数倍，规划时要一并计入；
  • 连接管理：计算层无状态，应用侧应通过负载均衡接入，避免绑定单实例。

把这四点想清楚，集群底座基本就能稳定支撑业务的长期增长。

架构层职责划分
计算层无状态 SQL 层，负责协议接入、语法解析、查询优化与算子执行，可横向增加实例
存储层负责数据持久化与多副本一致性复制，按 Region 分片，可横向增加节点
调度层维护集群元信息，负责 Region 负载均衡、副本位置调度与故障检测
扩展方式计算与存储分别扩缩容，扩容过程无需停机，业务侧基本无感知
容灾能力通过多副本与副本放置策略实现，可配置为同城或两地多中心部署