Redis集群扩容时Slot迁移导致性能急降的根本原因是默认批量并发迁移大量slot，引发CPU、带宽和磁盘I/O争抢，尤其源节点承载线上流量时易触发慢查询与CLUSTERDOWN；需手动分批迁移slot与key，严格控速并监控状态防卡死。
Redis集群扩容时Slot迁移为什么会导致性能急降
根本原因是 redis-trib.rb（或 redis-cli --cluster）默认的迁移方式会批量、并发地移动大量哈希槽（slot），每个 slot 迁移都包含：全量 RDB 生成 + 网络传输 + 目标节点加载 + 增量 AOF 同步。这三阶段都会争抢 CPU、带宽和磁盘 I/O，尤其当源节点同时承担线上读写请求时，CPU 和内存压力会直接触发慢查询、连接超时甚至 CLUSTERDOWN 报错。
用 --cluster-replicas 和 --cluster-yes 不解决限速问题
这两个参数只控制“是否跳过确认”和“副本数”，完全不干预迁移节奏。真正能控速的是底层 CLUSTER SETSLOT ... IMPORTING/MIGRATING 的调度粒度与频率。必须绕过自动工具，手动分批触发迁移：
- 每次只迁移 1 个 slot（
redis-cli -c -h src_host -p src_port CLUSTER SETSLOT 123 MIGRATING dst_node_id） - 配合
redis-cli -c -h dst_host -p dst_port CLUSTER SETSLOT 123 IMPORTING src_node_id - 用
redis-cli -c -h src_host -p src_port CLUSTER GETKEYSINSLOT 123 1000分批迁移 key（每次 ≤ 1000 个，避免单次命令阻塞） - 每完成一批 key 迁移后，sleep 1–3 秒，再继续下一批
如何监控迁移进度并防止卡死
迁移过程中最怕某 slot 卡在 MIGRATING 状态长期不结束，导致客户端持续收到 ASK 重定向，增加延迟。关键监控点有三个：
- 查迁移状态：
redis-cli -c -h node_host -p port CLUSTER NODES | grep -E "(MIGRATING|IMPORTING)"，确认只有预期 slot 处于该状态 - 看迁移积压：
redis-cli -h src_host -p src_port INFO | grep migrating，关注migrating_slots和migrating_keys是否持续下降 - 防卡死机制：如果某个 slot 迁移超过 5 分钟无进展，立刻
CLUSTER SETSLOT 123 STABLE回滚，并检查网络连通性与目标节点内存是否充足
生产环境建议的迁移节奏模板
不要追求“一晚上搬完”，而要按业务低峰期切片执行。例如每天凌晨 2:00–4:00 执行：
- 每轮处理 5 个 slot（不是 50 或 500）
- 每个 slot 内分 最多 5 批 key（每批 ≤ 1000 key，用
GETKEYSINSLOT+MIGRATE循环） - 每批 key 迁移后
sleep 2，每 slot 完成后sleep 5 - 全程用
watch -n 10 'redis-cli -h $SRC INFO | grep -E "used_memory|instantaneous_ops_per_sec"'观察源节点负载
真正的难点不在命令怎么写，而在于 slot 状态切换的原子性和 key 迁移失败时的幂等清理——比如 MIGRATE 超时后，必须手动在源节点 DEL 已迁出的 key，否则数据双写。这个细节没人提醒，但线上最容易出脏数据。
