数据 Rebalance 为什么要限速？

简化版

Rebalance 会同时消耗源端读、目标端写、跨机架网络、CPU 和临时空间；不限速可能把一次扩容变成前台超时和副本掉线。应按节点、磁盘、链路和租户设置带宽/并发预算，并用前台 P99、队列深度和恢复紧迫度动态调节；安全修复优先于普通均衡。

详细版

迁移通常包含快照复制、增量追赶、校验、所有权切换和旧副本清理。任何阶段都可能与前台请求、Compaction 和备份争抢资源。

例如 10 TiB 数据以 500 MiB/s 理想需约 5.8 小时，但若磁盘稳定余量只有 150 MiB/s，强推 500 MiB/s 会增加排队并抬高 P99。使用 120 MiB/s 虽需约 24.3 小时，却可能让业务保持 SLO。

限速要多维：每源/目标节点并发数、单任务速率、机架出口总带宽、集群迁移字节和单租户配额。只限单流无法阻止大量任务叠加。

控制器根据 P99、错误率、磁盘队列、网络利用率和 backlog 调速；前台恶化立即降速，低峰期逐步加速。切流必须在数据追平和校验后完成。

完整版教学

一、Rebalance 为什么不是后台免费任务

源节点要读历史数据，目标节点要写盘并构建索引，网络要传输，随后还可能触发 Compaction。资源路径与正常读写高度重合，因此“后台线程”不代表没有前台影响。

snapshot copy -> catch up log -> checksum -> switch owner -> observe -> delete old

二、用数字理解资源预算

10 TiB 按 500 MiB/s 传输的理论时间约为 5.8 小时，按 120 MiB/s 则约 24.3 小时。前者恢复快但可能打满磁盘；后者暴露在降副本状态更久。速率选择是业务风险与资源风险的权衡。

任务	紧迫度	常见策略
故障后补足副本	高	较高额度但保护前台
扩容均衡	中	平滑限速
成本优化搬迁	低	低峰执行
下线危险设备	高	按失效风险加速

三、为何要分层限速

单任务 50 MB/s 看似安全，但 20 个任务会形成 1 GB/s。需要 per-task、per-node、per-disk、per-rack 和 cluster-wide 多层令牌桶。源和目标任一侧预算不足都应等待，避免把压力转嫁给较弱一方。

跨 AZ 还受出口成本和带宽约束。调度器应避免多个大任务同时穿过同一链路，并考虑副本放置，不能为限速而把副本临时放进同一故障域。

四、自适应控制怎么做

固定速率无法覆盖昼夜流量。控制器可每 10～30 秒观察前台 P99、错误率、磁盘队列和网络，稳定时小步增速，越过保护阈值时快速降速。这类似 AIMD，但必须设置上下限和冷却期。

反馈指标要选前台信号而非只看带宽。SSD 带宽未满时，随机 I/O 队列也可能已让 fsync P99 恶化。

五、迁移正确性不能被限速破坏

限速可能让迁移跨越数小时，期间源端仍有新写。系统需记录 snapshot 水位并持续追增量；目标追到切换水位、checksum 通过后，控制面提升 epoch。旧 owner 随后只转发或拒绝旧写。

任务暂停和重启要可续传，并验证已传块，不能每次从零开始。旧副本在观察窗结束前保留，提供回滚路径，但不能被当成新写 owner。

六、调度公平与雪崩防护

大租户不能永久占满迁移池，小分片也不能因大任务队头阻塞。可按租户加权公平，并为紧急 repair 保留专用额度。节点大面积故障时，恢复流量会进一步拖慢存活节点，必须限制并发、优先恢复到法定副本数。

监控迁移吞吐、backlog、ETA、暂停率、重试字节、前台 P99、磁盘队列、降副本时长和故障域违规。ETA 需要用近期有效吞吐计算，而不是文件大小除以配置上限。

记忆钩子：Rebalance 限速不是让迁移越慢越好，而是使用“前台没用完的资源”尽快完成安全迁移。

七、常见误区与追问

• 误区：后台迁移不会影响线上请求。 它与前台共享磁盘、网络和 CPU。
• 误区：限制单任务带宽就够了。 多任务叠加仍可打满节点和机架出口。
• 误区：所有迁移优先级相同。 恢复副本安全通常高于普通均衡和成本优化。
• 追问：前台流量突增怎么办？ 快速降速或暂停低优先任务，保留状态后续续传。
• 追问：限速后如何保证增量不丢？ 记录快照水位并持续追日志，切流前验证追平。
• 追问：ETA 为什么会不准？ 实际吞吐受前台反馈、重试和 Compaction 影响，应动态估算。

八、加强记忆

Rebalance 是一条长期在线数据迁移：全量、增量、校验、切流、清理。限速要覆盖任务、节点、磁盘、链路和集群，并由前台 SLO 反馈调节；同时按安全紧迫度排优先级。快不是目标，在不压垮存活系统的前提下尽快恢复才是目标。