会，阻塞仅发生在源节点主线程且只影响当前迁移slot；cluster setslot migrating 仅设标记不迁移数据，返回ask重定向；真正阻塞的是同步的migrate命令，大key导致长时间卡顿，需分批处理并监控内存占用。

会，但阻塞发生在源节点的主线程，且只影响正在迁移的那个 Slot，不是整个节点或集群停摆。

CLUSTER SETSLOT migrating 命令本身不迁移数据

执行 CLUSTER SETSLOT <slot_id> MIGRATING</slot_id> 只是给源节点打个标记，告诉它“这个 Slot 正在往外搬”，并不触发任何数据传输。此时客户端访问该 Slot 的 key，源节点会返回 ASK 重定向，把请求甩给目标节点——但目标节点还没拿到数据，所以首次访问会失败（除非你手动先 MIGRATE 过）。

• 这个命令秒级完成，不卡顿
• 真正卡住的是后续的 MIGRATE 调用，尤其是遇到大 Key 时
• 日志里出现 Node X has slots in migrating state Y，说明标记已设，但迁移没走完

MIGRATE 命令是同步阻塞的，大 Key 是最大风险点

MIGRATE 是原子操作：源节点序列化整个 key（含所有 field/member）、网络发送、等待目标节点 RESTORE 返回 OK，全程独占主线程。一个 50MB 的 Hash 就能让线程卡死数秒，期间该节点无法响应任何其他命令。

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

• 不要用 redis-cli --cluster migrate 直接跑全量 —— 它底层就是反复调 MIGRATE，遇到大 Key 必卡
• 先用 CLUSTER COUNTKEYSINSLOT <slot_id></slot_id> 看总 key 数，再用 SCAN 0 COUNT 100 MATCH * 分批扫，对每个小 key 单独 MIGRATE
• 对疑似大 Key，先 MEMORY USAGE <key></key> 测体积，>1MB 的建议跳过、记录、后续人工处理
• 加 TIMEOUT 5000 参数，避免因网络问题无限 hang 住

卡死后不能等，必须用 CLUSTER SETSLOT STABLE 强制恢复

如果迁移中断（比如目标节点宕机、网络闪断、或大 Key 死锁），Slot 会长期卡在 MIGRATING 状态，集群元数据不一致，redis-cli --cluster check 会报错。这时候等自动恢复没用，得人工干预。

• 从日志里提取卡住的 slot ID（例如 15495）
• 登录对应源节点（不是目标节点），执行 CLUSTER SETSLOT 15495 STABLE
• 这条命令清除迁移标记，让 Slot 回归正常服务状态，客户端不再收到 ASK
• 注意：它不回滚已迁出的数据，只修复状态；已发到目标节点的 key 不会自动撤回

真正的难点不在命令怎么写，而在于识别哪个 key 是“沉默的炸弹”——它不报错、不超时、只是让整个 Slot 慢下来，直到你用 MEMORY USAGE 或 DEBUG OBJECT 扒开看内存占用才暴露出来。