先看INFO CPU中used_cpu_sys和used_cpu_user是否同步飙升：若仅sys飙升，是连接层压力；若两者齐涨且migrating_slots/importing_slots非零，才是数据迁移导致。
INFO CPU 里的 used_cpu_sys 和 used_cpu_user 是否同步飙升——如果不是，就别急着归因到数据迁移。
怎么快速区分是迁移导致的CPU冲高，还是客户端打爆了？
Redis集群扩容时CPU飙高，90%以上不是迁移本身的问题，而是客户端行为失控引发的连锁反应。
- 如果只有
used_cpu_sys显著升高（比如翻倍），used_cpu_user变化不大，基本是连接层压力：大量短连接重建、TLS握手、或客户端频繁重连 - 如果
used_cpu_sys和used_cpu_user同步上涨，再查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，过滤出是否集中发往正在迁移的源节点（而非随机打满所有节点）
为什么 redis-cli --cluster check 会拖慢迁移？
这个命令默认对每个槽执行 CLUSTER GETKEYSINSLOT + 多轮 SCAN，和 MIGRATE 争抢单线程资源，尤其在目标节点负载已高时，会卡住迁移队列并抬高 used_cpu_sys。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 迁移期间禁用自动
--cluster check，改用轻量轮询：redis-cli -h src -p 6379 cluster countkeysinslot {slot} 2>/dev/null对比redis-cli -h dst -p 6379 dbsize - 必须用
--cluster check时，加--verbose --slots 100限制抽样槽数（注意：仅 Redis 6.2+ 支持--slots参数） - 旧版本 Redis（如 4.x/5.x）无法限流，只能停机检查，别在迁移中跑
客户端响应延迟突增，到底是重定向开销大，还是键被锁住了？
MOVED 响应本身不耗时（纯文本），真正卡点在于客户端处理逻辑。而 TRYAGAIN 错误才是迁移中键被锁定的真实信号——此时源节点拒绝写入，客户端若没 sleep 就重试，会形成自旋风暴。
- 客户端必须识别
TRYAGAIN并主动sleep(50–100ms)后重试，不能当成普通失败立刻重发 - 避免在迁移窗口期执行
KEYS *、FLUSHDB、SCAN全量操作，它们会触发 slot 锁等待，放大阻塞 - 用
redis-cli --cluster rebalance --threshold 1可降低单次迁移槽数量，减小锁粒度（但要注意：该参数在 Redis 6.2+ 才生效）
TRYAGAIN 的静默忽略——它不像 MOVED 那样触发路由更新，也不像网络错误那样明显报错，但会让请求在源节点反复排队、超时、重试，最终表现为“延迟突增+CPU错峰上涨”。 
