Redis 集群节点扩容后的数据重平衡耗时没有固定标准，公开资料中没有看到可靠的量化数据，具体时长取决于数据总量、网络带宽及节点负载。监控重平衡过程推荐使用 redis-cli 原生命令结合 exporter 指标，重点观察 migrating_slots 计数与 CPU 使用率变化，避免在业务高峰期执行全量槽位迁移。

命令速用版

以下命令用于实时查看迁移进度与集群状态，需在任意节点执行：

redis-cli -c -p 6379 cluster nodes | grep -E "(migrating|importing)"
redis-cli -c -p 6379 info stats | grep migrating_slots
redis-cli -c -p 6379 cluster info

若 migrating_slots 或 importing_slots 数值大于 0，说明数据迁移正在进行中。

为什么会这样

数据重平衡本质是槽位（Slot）及其对应数据在不同节点间的物理移动。迁移过程中源节点需要读取数据、发送数据，目标节点需要接收并写入，这会消耗 CPU 与网络带宽。若迁移速度过快，可能触发源节点 used_cpu_sys 飙升，导致正常业务请求排队；若迁移速度过慢，则扩容效果迟迟无法体现。此外，迁移期间涉及键的锁定与重定向，客户端若未正确处理 MOVED 或 TRYAGAIN 错误，会表现为响应延迟突增。

分步处理

1. 检查迁移状态：执行 cluster nodes 命令，统计状态列包含 migrating 或 importing 的条目数量，确认是否有槽位正在迁移。

2. 监控资源负载：观察 INFO CPU 中的 used_cpu_sys 与 used_cpu_user。若只有 used_cpu_sys 显著升高，通常是网络或连接层压力；若两者同步上涨，说明迁移任务占用了计算资源。

3. 调整迁移速率：若发现 CPU 过高或业务延迟增加，可通过限制单次迁移槽位数量来降速，例如使用 redis-cli `--cluster` rebalance 时加上`--threshold` 参数减少单次迁移量。

4. 客户端适配：确保应用客户端库支持集群模式，能自动处理 MOVED 与 ASK 重定向，并在遇到 TRYAGAIN 错误时实现指数退避重试。

怎么验证是否生效

1. 槽位平衡：执行 cluster info 命令，检查 cluster_slots_assigned 与 cluster_slots_ok 是否等于 16384，且各主节点槽位数量大致均匀。

2. 负载回落：迁移完成后，节点 CPU 使用率应回落至扩容前的基线水平，无持续冲高现象。

3. 延迟恢复：监控客户端响应延迟（RT），确认迁移结束后的 P99 延迟与业务低峰期持平，无异常毛刺。

常见坑

1. 迁移期间禁用自动检查：redis-cli `--cluster` check 默认会遍历所有槽位并执行抽样，在迁移进行中会与 MIGRATE 命令争抢单线程资源，直接抬高 used_cpu_sys 并阻塞迁移队列，建议改用轻量轮询命令 cluster countkeysinslot。

2. 客户端重试风暴：若客户端未正确处理重定向错误，可能在迁移期间产生大量重试请求，导致 CPU 进一步升高，形成恶性循环。

3. 大键迁移阻塞：单个大 Key 迁移耗时过长会阻塞源节点单线程，建议提前扫描大 Key 并在低峰期单独处理。

常见问题

重平衡一般需要多久完成？

公开资料中没有看到可靠的量化数据，时长完全取决于数据量和网络状况，小集群可能几分钟，TB 级数据可能需要数小时。

迁移期间业务会中断吗？

理论上不会中断，但延迟可能波动，客户端需支持自动重定向，否则部分请求会报错。

可以用什么工具监控迁移进度？

推荐使用 redis_exporter 配合 Prometheus/Grafana 监控 migrating_slots 指标，或使用云厂商控制台的集群监控页面。

参考来源

• Redis 怎样评估集群扩容的性能损耗_监控数据迁移过程中的 CPU 冲高与客户端响应延迟增量
• Redis 缓存高可用监控：实时监控内存碎片率、缓存命中率、Key 驱逐及集群节点状态_redis 监控 fd agen-CSDN 博客
• Redis 集群全攻略：核心操作与精细化状态监控 - 华为企业互动社区
• 查看监控数据 - 云数据库 Redis 控制台说明