redis-cli --cluster rebalance 需配合--cluster-use-empty-masters才能收编未分配槽位；未分配槽位指无任何节点负责的槽，可通过redis-cli --cluster check检查输出中“slots covered but only x slots assigned”确认。
redis-cli --cluster rebalance 是唯一能自动识别并填补未分配槽位的命令，但必须配合 --cluster-use-empty-masters 才生效——不加这个参数，新加入的空主节点永远分不到槽，未分配槽位也永远不会被收编。
未分配槽位怎么确认？
不是所有“槽没数据”都叫未分配，关键是看槽是否归属任何节点：
运行 redis-cli --cluster check 192.168.1.101:7001，如果输出里出现 *** ERROR: 16384 slots covered, but only X slots assigned（X 更直接的方式是执行 redis-cli -c -h 192.168.1.101 -p 7001 cluster slots，返回结果中若缺失某段连续槽区间（比如没有 5000-5999 这一段），且无任何节点声明负责，就是未分配。
rebalance 命令为什么默认不处理空节点？
redis-cli --cluster rebalance 的设计逻辑是「在已有主节点之间搬槽」，它默认忽略状态为 myself,master 但 slots: 后为空的节点（即刚 CLUSTER MEET 进来的空 master）。这是为了防止误把运维误操作的孤立节点卷入均衡流程。
所以必须显式加 --cluster-use-empty-masters，告诉工具：“这些空节点是合法目标，请把未分配槽或偏斜槽往它们身上分”。
常见错误：只运行 redis-cli --cluster rebalance 192.168.1.101:7001，结果提示 No need to rebalance，其实是因为它根本没看见空节点。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
执行 rebalance 前必须检查三件事
- 所有节点状态为
connected且无fail标记（用redis-cli cluster nodes确认） - 待接收槽的空节点已通过
CLUSTER MEET加入集群，并在cluster nodes输出中显示为master+myself - 目标空节点内存足够——rebalance 过程会把键值对同步过去，如果目标节点内存已接近上限，迁移中途会卡在
MIGRATING状态不动
rebalance 和 reshard 在未分配槽场景下的分工
未分配槽 ≠ 槽位偏斜：rebalance 解决的是“槽没人要”，它会把未分配槽均匀塞进符合条件的空 master 节点；reshard 解决的是“槽分得不匀”，比如 nodeA 有 6000 槽、nodeB 只有 4000 槽，但它无法处理完全没人 claim 的槽位。
如果你发现 cluster slots 输出里有一大片槽（比如 12000-16383）彻底消失，那一定是 rebalance --cluster-use-empty-masters 的事，不是 reshard 能干的。
真正容易被忽略的点是：rebalance 不会主动清理残留的 importing/migrating 标志。如果之前迁移中断过，某些槽可能卡在中间态，导致 rebalance 认为“这槽已被占用”而跳过——此时得先人工用 CLUSTER SETSLOT <slot> STABLE</slot> 清掉状态，再跑 rebalance。
