版本说明

本文基于 Redis Cluster 5.x/6.x 的 redis-cli --cluster 工具链，slot 状态机在 7.x 上未发生变化，仍适用。

1. 现象

给 Redis Cluster 加节点、做 slot 迁移（redis-cli --cluster reshard）的过程中，如果中途被打断（网络抖动、手动 Ctrl-C、迁移脚本异常退出），再执行集群健康检查会报错：

redis-cli --cluster check <PUBLIC_IP>:8001

>>> Check for open slots...
[WARNING] Node <INTERNAL_IP>:8001 has slots in importing state 11763.
[WARNING] The following slots are open: 11763.

集群此时能正常读写（大部分 slot 状态正常），但这个 11763 slot 处于一种"悬空"状态，--cluster check 会持续报警，如果不处理，后续再做别的 reshard 操作大概率会失败或报更多冲突。

2. 定位：为什么会卡在"open slots"

Redis Cluster 迁移一个 slot 分两步——源节点标记为 MIGRATING，目标节点标记为 IMPORTING，等这个 slot 里所有 key 都从源节点搬到目标节点后，再把 slot 的归属正式切给目标节点（状态变回 stable）。

根因：如果迁移在"key 已经搬完但状态还没切换成 stable"或"搬到一半就中断"这个中间态被打断，slot 就会一直卡在 importing（或对应地在源节点卡在 migrating），这是 Redis Cluster 迁移协议本身的设计——它不会自动回滚或自动完成，需要人工介入确认这个 slot 到底应该属于哪个节点，再手动收尾。

先确认这个 slot 里的 key 是否已经搬空：

<INTERNAL_IP>:8001> cluster countkeysinslot 11763
(integer) 0

0 表示 key 已经全部迁移完成，只是状态没有切换——这种情况可以直接安全收尾；如果这里不是 0，说明迁移没搬完，需要先用 redis-cli --cluster fix 或手动继续搬迁 key，不能直接强行改状态，否则会丢数据。

3. 修复：手动把 slot 状态切回 stable

确认 key 已搬空后，在目标节点上执行：

<INTERNAL_IP>:8001> cluster setslot 11763 stable
OK

stable 是告诉这个节点"停止迁移状态、这个 slot 正式归你了"。如果源节点上也残留了 migrating 状态，同样对源节点执行一次 cluster setslot 11763 stable。

4. 验证

redis-cli --cluster check <PUBLIC_IP>:8001

确认输出不再出现 open slots 的 WARNING，且 [OK] All 16384 slots covered 这类总结行出现，说明所有 slot 都有明确归属、集群拓扑一致。

5. 坑

• 不要在 key 还没搬完时就执行 setslot stable——这会导致这批未搬完的 key 在逻辑上"丢失"（既不在源节点的正常 slot 范围，也没真正进入目标节点），必须先用 cluster countkeysinslot 确认为 0。
• 命令行里带 -a password 会触发一条安全警告（Using a password with '-a' ... may not be safe）——这是提示密码可能出现在 shell 历史/进程列表里，不是操作失败，用 --pass 从环境变量或配置文件读取密码可以避免。
• 迁移类操作尽量用 redis-cli --cluster reshard 走官方工具链而不是纯手动逐条搬 key，工具会自动处理 migrating/importing 状态机的两端同步，减少中途中断留下悬空 slot 的概率。

6. 可复用要点

1. open slots 报警的本质是迁移协议的中间态没有收尾，Redis 不会自动处理，需要人工判断并执行 setslot stable。
2. 收尾前必须用 cluster countkeysinslot 确认目标 slot 是否已经搬空——这是唯一能安全下断言的检查点。
3. 优先用 redis-cli --cluster reshard 而不是手动裸命令迁移，减少人为中断留下悬空状态的概率。