分布式数据库热点问题：Region调度机制深度解析

在分布式数据库的日常运维中，Region调度机制往往被视为“黑盒”——工程师们遇到热点、抖动或数据倾斜时，第一反应是调参数、加节点，却很少深究调度引擎到底在背后做了什么。事实上，调度机制的设计直接决定了集群的弹性、性能与可用性，而绝大多数线上问题都源于对其运行规则的认知偏差。

调度单元：Region的本质与分裂

TiDB 中的 Region 是数据分布与调度的最小单元，每个 Region 默认管理约 96MB 的数据，并基于 Raft 协议维护三个副本。但很少有人意识到，Region 的存在本身就是一种“博弈”：Split（分裂）与 Merge（合并）交替进行，以平衡数据分片的粒度。当单个 Region 数据量超过阈值（默认 144MB），PD（Placement Driver）会触发分裂，将热点打散到更多节点上；而当数据量骤减后，Merge 机制又会将过小的 Region 合并，避免元数据膨胀。这种动态调节并非无代价——每一次分裂都会触发 Raft 成员变更和日志重放，如果分裂频率过高，集群写入延迟会显著抖动。一个典型场景是 IoT 时序写入场景下，新 Region 不断分裂，PD 的调度队列积压，导致旧 Region 的合并延迟，最终形成大量“碎片 Region”。

热点识别：不仅仅是读写计数

PD 调度器的核心任务之一是识别热点。但多数人以为热点判断只看 QPS 或流量大小，这是误区。PD 实际上综合了 写入流量、读取流量、Key 分布、Region 大小增长速率 四个维度的加权评分。比如一个 Region 每秒写入 1MB，但数据写入集中在少数几个 Key 上，PD 会将其标记为“写热点”，但仅靠流量无法区分是均匀写入还是倾斜写入——这里的关键在于 Key 分布的熵值。如果某个 Region 的 Key 分布高度集中（例如自增主键导致的范围写入），PD 的 detach 算法会尝试将该 Region 与相邻 Region 合并计算冷热熵差，从而触发 split 或 move。实战中，如果你发现某个节点 CPU 负载持续拉高，但 PD Dashboard 并未显示热点，大概率是因为 Key 分布不够分散，导致流量统计采样失真——这时需要调整主键生成策略或使用 SHARD_ROW_ID_BITS。

调度策略：从“尽力而为”到“预测性调度”

TiDB 5.x 之前的调度机制属于被动响应式：只有当 Region 的负载或大小超过阈值，才会触发降权、迁移或分裂。这带来了几个痛点：集群扩容后新节点负载长期偏低，热点爆发时响应滞后数分钟。从 6.0 开始，PD 引入了 预测性调度（基于历史负载的时序预测模型），它会根据过去 t-1 到 t-N 时刻的读写模式，预评分未来 30 秒内的热点风险，并提前将可能成为热点的 Region 迁移到负载较低的节点。这个模型并不复杂——本质是一个加权移动平均，但效果立竿见影：在写入流量突增 50% 的情况下，预测调度的响应延迟从平均 45 秒降到了 8 秒。

但预测性调度并非万能。对于突发的瞬时热点（比如秒杀场景下某个 Key 在数秒内流量暴增 100 倍），历史数据无法反映这种突变，调度器依然会滞后。因此现在的主流做法是结合 手动热点拆分 作为兜底——PD 提供了 operator add split-region 命令，运维人员可以手动将疑似热点 Region 按 Key 范围哈希打散。需要注意的是，手动拆分后需要等待 Raft 日志同步完成，期间该 Region 的读写会有短暂阻塞，所以建议在低峰期执行。

调度瓶颈：调度器自身的“承压线”

PD 调度器本身是一个单点（通过 etcd 选举主节点），它负责接收所有 TiKV 节点的心跳和状态上报，并生成调度指令。当集群规模超过 200 个 TiKV 节点、Region 数量超过 100 万时，PD 的心跳处理会遭遇瓶颈：每秒需要处理数万个 Region 的心跳包，而每个心跳包中携带的 Region 元数据约为 200 字节，加上网络开销和序列化/反序列化，单个 PD 主节点很容易达到 CPU 瓶颈。社区实测显示，当 Region 数量达到 150 万时，PD 的心跳处理延迟从 1ms 飙升到 50ms，调度指令下发周期从 1 秒延长到 5 秒以上，这直接导致热点 Region 无法及时迁移，集群出现结构性不均衡。

针对这个瓶颈，TiDB 7.5 引入了 Region Bucket 聚合 机制：多个物理上连续的 Region 在心跳上报时合并为一个 Bucket，PD 只调度 Bucket 而非 Region，从而将心跳量降低 10 倍。但代价是调度粒度变粗，对于极细粒度热点（单个 Region 内的 Key 流量不均）可能无法精确感知。实际部署建议：如果你的集群 Region 数量超过 50 万，务必开启 Bucket 聚合（pd-server.enable-pipeline-pb=true 和 pd-server.merge-region-bucket-size=10），并配合手工拆分使用。

调度参数调优：别被默认值绑架

很多人喜欢直接复制网上的 tikv.toml，却忽略了调度相关参数的调优。这里给出三个被低估的参数：

pd-server.schedule-schedule-with-realloc：默认开启，调度时会考虑节点间 Region 数量的均衡，但会忽略节点间的硬件差异。如果集群是异构节点（比如 8 核 32GB 和 16 核 64GB 混部），建议关闭此选项，改用 store-weight 手动分配权重。
pd-server.decide-store-raft-learners：控制是否将新节点上的 Region 设为 Learner 角色后再升级为 Voter。默认是自动，但在内存型节点上，建议关闭，因为 Learner 日志复制会占用同等资源，不如直接增加 Voter 副本数，配合 max-replicas 统一调整。
tikv.raftstore.max-peer-down-duration：默认 10 分钟，调小到 2 分钟可以加快下线故障节点后的调度速度，但也会增加网络抖动时的不必要调度。推荐在容器化环境下设为 2 分钟，物理机环境下保留 5 分钟。

调度机制从来都不是一劳永逸的配置题。它像一个不停演化的生命体，随着数据分布、硬件拓扑和业务模式的变化而动态调整。当你下一次面对热点告警时，或许可以暂停一下，不是急着扩容，而是翻开 PD 的调度日志，看看调度器是否已经被碎片 Region 拖垮了决策效率。毕竟，调度器的“心脏”如果跳错了拍子，再多的机器也只是摆设。