扩容为什么常常需要停机
传统分库分表方案扩容时，需要人工决定哪些分片迁到新库、迁移期间如何双写、如何保证一致性，往往要安排停机窗口。这类工作的复杂度随分片数量非线性上升，扩容因此变成一件让人回避的事。
计算与存储分离的架构把扩容变成了自动化的常规操作，因为它把「数据分布」这件事从应用层收到了存储层。
计算层扩容：加实例即可
计算层是无状态的，不保存业务数据。因此扩容计算能力的动作非常轻：
- 部署新的计算节点实例并加入集群；
- 将其注册到负载均衡或服务发现中；
- 连接层逐步把新连接引流到新实例。
这个过程不涉及数据搬迁，因此几乎没有数据风险。需要注意的反而是连接层：如果应用侧使用了长连接或连接池，新建的连接才会走到新实例，扩容效果不会立刻体现，必要时需要配合连接池的重建或分批重启。
存储层扩容：自动搬迁分片
存储层的扩容要复杂一些，因为涉及真实的数据搬迁。基本流程是：
- 新节点加入集群并被调度中心识别；
- 调度中心根据各节点的负载与容量情况，决定把哪些 Region 迁到新节点；
- 按 Region 逐个做副本迁移，先在新节点补齐副本，再移除旧副本，整个过程由一致性协议保证安全；
- 迁移完成后重新平衡各节点的 Leader 分布。
由于迁移以 Region 为单位、并遵循一致性协议，扩容过程可以在线进行，业务读写不中断。数据量越大，搬迁耗时越长，但业务侧通常只表现为一段时间内的延迟轻微上升。
缩容同样重要
业务低谷时把多余节点下线，能直接降低成本。缩容的流程与扩容对称：先把待下线节点上的副本与 Leader 调度到其他节点，确认该节点不再承载数据后再摘除。要注意的是缩容会降低冗余度，应确认剩余节点的容量与副本数仍满足容灾要求。
扩容期间的工程要点
- 错峰操作：把扩容安排在业务低峰，搬迁带来的额外 IO 与网络开销更容易被吸收；
- 控制搬迁速度：迁移过快会挤占正常读写资源，多数系统提供并发与限速参数，应结合在线负载调整；
- 关注热点：如果写入集中在一小段键区间，扩容并不能解决热点，需要先治理键设计；
- 容量预留：多副本存储意味着实际占用高于数据量，规划时留出足够水位；
- 验证读扩散：扩容后读请求会分散到更多节点，确认网络与中间件配置能跟上。
什么时候该扩
不要等打满再扩。比较稳妥的做法是设定容量水位线与延迟基线，当磁盘使用率、CPU 或写入延迟持续接近阈值时就启动扩容，把自动化流程的耗时计入提前量。这样扩容就成为一种可预测的日常运维动作，而不是救火。
| 计算层扩容 | 启动新实例并接入负载均衡，无数据搬迁，风险低但受连接复用影响 |
|---|---|
| 存储层扩容 | 新节点加入后由调度中心按 Region 自动迁移副本并重新平衡 Leader |
| 业务影响 | 在线进行不中断，可能表现为短时延迟轻微上升 |
| 缩容 | 先调度走副本与 Leader，确认无数据承载后摘除节点 |
| 关键限制 | 无法解决键设计导致的热点，需要先治理数据分布 |
