先看INFO CPU中used_cpu_sys是否单独飙升，若是则为连接层压力；若user和sys同步涨，再查cluster中migrating_slots/importing_slots是否非零，并结合客户端重试日志与抓包定位根因。
Redis集群扩容时CPU飙升，怎么快速定位是迁移还是客户端打爆的？
Redis集群扩容期间CPU冲高，不能默认归咎于数据迁移。实际中更常见的是客户端重试风暴或连接复用失效导致的请求堆积。先确认 INFO CPU 里的 used_cpu_sys 和 used_cpu_user 是否同步飙升——如果只有 used_cpu_sys 显著升高，大概率是网络/连接层压力（比如大量短连接重建）；如果两者都涨，再查 INFO cluster 中 migrating_slots 和 importing_slots 是否非零。
- 查看迁移活跃度：
redis-cli -c -h node1 -p 6379 cluster nodes | grep -E "(migrating|importing)" - 抓包验证请求来源：
tcpdump -i lo port 6379 -w redis-cpu.pcap，过滤出是否集中发往正在迁移的源节点 - 检查客户端日志里是否有密集的
MOVED或ASK重定向响应，这是重试逻辑没兜住的典型信号
监控数据迁移进度时，redis-cli --cluster check 为什么反而拖慢迁移？
redis-cli --cluster check 默认会遍历所有槽位并执行 CLUSTER GETKEYSINSLOT 抽样，对每个槽发起多次 SCAN 请求。在迁移进行中，这会和 MIGRATE 命令争抢单线程资源，尤其当目标节点负载已高时，直接抬高 used_cpu_sys 并阻塞迁移队列。
- 迁移期间禁用自动
check，改用轻量轮询：redis-cli -h src -p 6379 cluster countkeysinslot {slot} 2>/dev/null配合redis-cli -h dst -p 6379 dbsize对比增量 - 如果必须用
--cluster check，加--verbose并限制抽样数：--cluster check --verbose --slots 100 - 注意：该命令在 Redis 6.2+ 才支持
--slots参数，旧版本只能停机检查
客户端响应延迟突增，是重定向开销大，还是迁移锁住了键？
Redis集群里 MOVED 重定向本身不耗时（纯文本响应），真正延迟来自客户端处理重定向后的二次请求链路。但若出现某几个键持续超时，大概率是这些键正被 MIGRATE 锁定——迁移过程中，源节点对正在迁移的键会短暂拒绝写入（返回 TRYAGAIN），客户端若没正确处理该错误，就会卡住或无限重试。
- 客户端必须识别
TRYAGAIN并主动 sleep 后重试（推荐 50–100ms），而非当成普通失败立刻重发 - 避免在迁移窗口期执行
KEYS *、FLUSHDB等全量操作，它们会触发 slot 锁等待 - 使用
redis-cli --cluster rebalance时，加上--threshold 1可减少单次迁移槽数量，降低锁粒度
从监控指标看，哪些数值能提前预警迁移风险？
别等 CPU 到 90% 才反应。以下三个指标组合看，比单独看 CPU 更早暴露问题：
-
instantaneous_ops_per_sec在源节点持续低于目标节点 30% 以上，说明迁移吞吐跟不上写入节奏 -
rejected_connections在目标节点突然上升，代表maxclients或内存不足，迁移会卡在WAIT状态 -
sync_full在目标节点持续为 0，但sync_partial_ok频繁下降，说明主从复制缓冲区溢出，影响迁移稳定性
迁移不是“开始→结束”的原子过程，而是多个槽分批、异步推进的流水线。最容易被忽略的是：迁移中的槽，其读请求仍由源节点服务，但写请求可能被 TRYAGAIN 拦截——这个状态在监控里没有专用指标，只能靠 slowlog get 里频繁出现的 MIGRATE 调用和客户端错误日志交叉印证。
