CLUSTER ADDSLOTS执行后槽位仍unassigned，主因是节点未完成握手、状态为fail/noaddr未清理、或本地槽位表清空；需先确保节点在线且状态正常，再分批执行合法十进制槽号分配。
槽位丢失不是数据丢了，而是集群元数据不一致——CLUSTER ADDSLOTS 能补上槽位映射，但前提是目标节点已正确握手、状态为 fail 或 noaddr 的节点必须先清理。
为什么 CLUSTER ADDSLOTS 执行后槽位还是显示 unassigned
常见于节点重启后未自动载入配置，或手动执行 CLUSTER RESET 导致本地槽位表清空。Redis 不会自动从其他节点同步槽位分配，只靠 CLUSTER MEET 和后续的 CLUSTER ADDSLOTS 显式声明。
- 执行前必须确认该节点已通过
CLUSTER NODES出现在集群列表中，且状态不是fail（否则槽位无法归属） - 不能对
myself标记为noflags以外状态的节点直接加槽；若节点被标记为fail，需先用CLUSTER FORGET清除旧记录，再重新MEET -
CLUSTER ADDSLOTS只接受十进制整数，不能写成十六进制或带空格的范围，例如1234 1235 1236合法，0x4D2或"1234-1236"会报错(error) ERR Invalid slot ID specified
一次安全补全 16384 个槽位的操作顺序
适用于全新节点加入或旧节点重置后重建槽位分配。核心原则：先确保节点在线且可通信，再逐段分配，避免单次命令过长触发协议解析失败。
- 用
redis-cli -c -h {node} -p {port}连上待分配槽位的节点 - 运行
CLUSTER NODES确认该节点 ID 和状态（应为myself,master） - 按每批 1000 个槽位分段执行，例如：
CLUSTER ADDSLOTS 0 1 2 ... 999
，再执行1000 1001 ... 1999，依此类推 - 每次执行后立即用
CLUSTER SLOTS验证是否生效；若返回空数组或报错，说明节点尚未完成握手或存在网络隔离
遇到 (error) ERR Slot XXX is already busy 怎么办
表示这个槽位当前已被另一个节点声称拥有，属于典型的“槽位冲突”。不是数据损坏，是集群视图分裂导致的元数据不一致。
- 先查谁占着：在任意节点执行
CLUSTER SLOTS，找到包含该槽号的区间，看对应节点 ID - 检查那个节点是否存活：用
CLUSTER NODES | grep {node_id}，若状态为fail或无响应，需在所有节点上执行CLUSTER FORGET {node_id} - 若冲突节点仍在线且你确定要迁移，必须先用
CLUSTER SETSLOT {slot} MIGRATING {target-node-id}发起迁移，而不是强行ADDSLOTS - 切忌在多个节点上并发执行
CLUSTER ADDSLOTS相同槽位——这会让集群彻底失去一致性，可能触发CLUSTERDOWN错误
真正麻烦的从来不是加槽本身，而是加之前没确认节点间心跳是否稳定、cluster-enabled yes 是否全局生效、防火墙是否放行集群总线端口（redis-port + 10000）。这些细节漏掉一个，CLUSTER ADDSLOTS 就只是往空气里扔命令。
