应拆解自动流程，用底层命令逐环节验证：先手动执行migrate测试小key，检查超时值、认证、dns解析、目标内存及loading状态；再分别监控源节点migrating_keys下降趋势和目标节点loading状态，避免隐式并发堆积。
redis-cli --cluster reshard 迁移时超时，怎么定位是哪一环卡住了
默认 redis-cli --cluster reshard 不暴露迁移过程细节，超时后只报 Timeout connecting to node 或 MIGRATE failed，但无法判断是源节点卡、目标节点卡，还是网络/认证/配置挡在中间。必须拆开自动流程，用底层命令逐环节验证。
关键动作是：在迁移前，手动对目标节点执行一次最小化 MIGRATE 测试 —— 选一个已知小 key（如 test:key），显式带上所有参数：
redis-cli -h $SRC_HOST -p $SRC_PORT MIGRATE $DST_HOST $DST_PORT test:key 0 5000 REPLACE AUTH $DST_AUTH
这个命令能同时验证五件事：
-
5000超时值是否合理（太小会假失败，太大掩盖真实瓶颈） - 目标节点
$DST_AUTH是否正确（AUTH 失败不报错，只静默 hang） - 源节点能否解析
$DST_HOST（DNS 或 hosts 未配会导致连接超时） - 目标节点
maxmemory是否充足（INFO memory中used_memory接近maxmemory时，MIGRATE会阻塞等待内存释放） - 目标节点是否处于
loading状态（INFO | grep loading返回loading:1，说明它还在加载上一批 RDB，此时发新MIGRATE会排队）
如何实时观察 migrating_keys 下降趋势，而不是只看 CLUSTER NODES
CLUSTER NODES 只显示槽位状态为 migrating，但不反映实际进度。真正有用的指标藏在 INFO 输出里，且必须分别查源、目标节点。
源节点重点关注：
redis-cli -h $SRC_HOST -p $SRC_PORT INFO | grep -E "migrating_slots|migrating_keys|instantaneous_ops_per_sec|used_memory"
其中 migrating_keys 是当前待迁移 key 总数，每批 MIGRATE 后应下降；若长时间不变，说明后续 MIGRATE 全部失败或被阻塞。
目标节点必须同步盯住：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -h $DST_HOST -p $DST_PORT INFO | grep -E "loading|rejected_connections|evicted_keys"
特别注意：loading:1 持续超过 10 秒，基本可判定目标节点磁盘 I/O 或 CPU 已成瓶颈；evicted_keys 非零，说明 maxmemory-policy 开始驱逐，迁移数据可能被删。
为什么 timeout 参数设了 5000 还总超时？真正起作用的是这三个地方
MIGRATE 命令的 timeout 参数只是 socket 层连接 + 首包响应的上限，它压不住整个迁移链路的真实耗时。以下三处才是实际卡点：
- 源节点执行
CLUSTER GETKEYSINSLOT时，如果该 slot 下 key 数量极大（比如百万级），命令本身就会阻塞几秒——这不是timeout能控制的，得靠分批（count=1000）和监控slowlog get 5 - 目标节点反序列化 RDB 片段时，若 key value 很大（如 10MB 的 hash），单 key 加载就可能耗时 2s+，而
timeout对这个阶段无效 - 网络中间件（如 Kubernetes Service、SLB）的 idle timeout 小于
MIGRATE实际耗时，导致连接被主动断开，客户端看到的仍是 “timeout” 错误
验证方式：在源节点抓包 tcpdump -i any port $DST_PORT -w migrate.pcap，看 FIN 包是目标节点发的，还是中间设备发的。
最容易被忽略的隐式并发：loading 状态下的 MIGRATE 排队
当目标节点 INFO 显示 loading:1，它正在把收到的 RDB 数据写入内存。此时再向它发 MIGRATE，请求不会立刻失败，而是进入内部队列等待。队列长度无限制，多个 MIGRATE 请求堆积后，实际并发远高于你控制的“每秒 1 批”。更危险的是，这些排队请求共享同一个超时计时器，一旦超时，全部失败，重试又加剧排队。
所以监控不能只看 migrating_keys 是否下降，更要每 5 秒执行一次：
watch -n 5 'redis-cli -h $DST_HOST -p $DST_PORT INFO | grep loading'
只要 loading:1 存在，就暂停向该节点发任何新 MIGRATE，哪怕 migrating_keys 还剩几千个。
