分布式数据库分片自动扩展

分片机制

某个数据表，分片数量是固定的，如256

当你执行 INSERT 或 SELECT 时，数据库（或中间件 Proxy）会拿到你指定的 Shard Key（分片键），然后丢进公式里：

Shard_ID=Hash(Shard_Key)(mod256)Shard\_ID = Hash(Shard\_Key) \pmod{256}Shard_ID=Hash(Shard_Key)(mod256)

这张图非常清晰地展示了 TDSQL（以及类似架构的分布式数据库）是如何从逻辑分片 演进到物理扩容的过程。

我们可以把这张图分为三个阶段来解读：

SQL 引擎 (Proxy)： 这是用户直接接触的层。对你（开发者）来说，你看到的只有一张巨大的表 G。
透明性： 你不需要关心数据具体在哪。你只需要发送 SELECT * FROM G WHERE id = ...，SQL 引擎会自动帮你计算这行数据应该去哪个"小表"里找。

这里是理解分片的关键：在 TDSQL 中，数据表被预先切分成了固定数量的"逻辑分片"（也叫 Group）。

预分片 (Pre-sharding)： 图中显示表 G 被拆分成了 G0 到 G255，总共 256 个逻辑分片。
初始状态 (Set 00)： 在业务初期，数据量并不大。为了节省成本，这 256 个逻辑分片可以全部挤在 Set 00 这一个物理容器里（也就是一组 1 主 2 从的 MySQL 实例）。
此时的卦象： 逻辑上是分布式的，但物理上是单点的。这时候性能瓶颈在于这个物理 Set 的 CPU 和磁盘。

当业务爆发，Set 00 的压力太大时，这张图的核心动作------拆分就发生了：

这个过程通常被称为平滑迁移，其目标是在业务无感的情况下，将逻辑分片从一个物理 SET 搬迁到另一个物理 SET。

以下是分片迁移的详细深度拆解：

迁移过程通常分为四个关键阶段：

全量同步（Full Sync）：
- 系统在源 SET（源节点）上创建一个数据快照。
- 将快照数据发送到目标 SET。此时，业务依然在源 SET 上进行读写。
增量同步（Incremental Sync）：
- 在全量迁移期间产生的增量数据（如 MySQL 的 Binlog），会通过实时解析并回放到目标 SET 中。
- 目标 SET 追赶进度的过程是持续的，直到两边的数据差异（Lag）极小。
一致性校验：
- 在切换前，后台会对源和目标的数据进行抽样或全量校验，确保搬迁没有导致数据损坏。
切流切换（Switch / Cutover）：
- 这是最关键的一步。系统会将路由信息指向新的 SET。

现代分布式数据库追求 Lock-free（无锁） 或 Minimal Lock（最小锁）。

全量与增量阶段：完全无锁。 业务读写不受影响。源库通过 MVCC（多版本并发控制）读取快照，不阻塞写操作。
切换阶段：存在"瞬时禁写"。
- 为了保证数据绝对一致，在路由信息正式更新前的最后几毫秒，源 SET 会进入一个极短的 ReadOnly（只读） 状态。
- 在这几毫秒内，系统等待最后的增量日志追平。
- 感官影响： 业务侧可能会感受到一个很小的耗时抖动（毫秒级），通常不会导致连接断开，只会有短暂的请求延迟增加。

路由信息的更新是实现"平滑"的关键，涉及到 Proxy（网关） 和 元数据中心（Metadata/Catalog） 的配合：

元数据状态变更：
- 当数据追平并准备切换时，调度中心会在元数据数据库（如 TDSQL 的 ZooKeeper 或内部元数据库）中将该分片的指向从 SET_A 更新为 SET_B。
路由下发：
- Proxy 会感知到元数据的变化。此时，旧的请求如果还在发往 SET_A，Proxy 会根据新的路由配置将其重定向到 SET_B。
路由预热与刷新：
- 有些架构会采用"预推"机制，先让 Proxy 知道即将切换，等真正切换指令下达时，Proxy 瞬间完成切换。