redis-cli --cluster reshard是唯一推荐的在线修复槽位分布不均手段，需严格按“选目标、定数量、挑来源、确认执行”四步交互操作，避开客户端缓存未刷新、源节点负载突增、目标节点内存不足三大陷阱。
Redis Cluster 槽位分布不均不是配置错误，而是槽位归属权没及时调整——redis-cli --cluster reshard 是唯一推荐的在线修复手段，无需停机、不丢数据，但必须避开客户端缓存未刷新、源节点负载突增、目标节点内存不足这三个典型陷阱。
怎么用 reshard 手动迁移指定数量槽位
交互式命令本质是「选目标、定数量、挑来源、确认执行」四步，不是脚本化操作，每一步都可能卡住或出错：
-
redis-cli --cluster reshard 192.168.1.101:7001启动后，第一问是迁移槽数量（如600），不能填 0 或超过 16384，填错直接退出 - 第二问是接收节点 ID，必须从
redis-cli cluster nodes输出中复制完整 ID（如2728a594a0498e98e4b83a537e19f9a0a3790f38），少一位或大小写错都会报No such node - 第三问是源节点，填
all表示从所有主节点等比例抽槽；填单个 ID 则只从该节点迁出；填错 ID 或漏填会卡在「Source node 1:」不动 - 最后提示 plan 时务必核对输出里的
source和destination是否符合预期，yes一按就不可逆
为什么 reshard 迁移后客户端还在打老节点
不是命令失败，是客户端没收到或没处理 MOVED 重定向。Lettuce、Redisson 等现代客户端会自动更新 slot-node 映射，但有前提条件：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端必须启用集群模式（如 Lettuce 的
RedisClusterClient，不是RedisClient） - 迁移完成前已建立连接的旧连接不会自动刷新映射，需等待连接池自然轮换，或手动调用
client.reloadPartitions() - 若用
redis-cli -c测试，每次命令都是新连接，能立即生效；但业务代码里复用连接时，可能持续打错节点 1–2 分钟 - 检查是否误用了
ASK响应（迁移中）和MOVED响应（已切换）——只有MOVED才触发客户端永久更新路由表
什么时候该用 rebalance 而不是 reshard
rebalance 是自动计算+迁移，适合「整体偏斜但无明确目标节点」的场景；reshard 是人工指定，适合「精准补槽、扩容加节点、缩容清空某节点」：
- 运行
redis-cli --cluster rebalance --cluster-threshold 2 192.168.1.101:7001：表示只要节点间槽位差 > 2 个，就启动均衡，但默认只在主节点间搬，不碰从节点 -
--cluster-use-empty-masters参数必须显式加，否则新加入的空 master 节点永远分不到槽 -
rebalance不会跨机房/跨可用区迁移，而reshard可以——如果你的集群混布了不同区域节点，只能手选源节点 ID - 自动均衡可能一次搬上千槽，引发短时带宽打满；
reshard每次可控数量（建议单次 ≤500），更适合生产环境灰度
真正容易被忽略的是迁移期间的键倾斜：哈希标签（{user1001}）会让大量键挤进同一个槽，哪怕槽位数均等，实际数据量仍可能差 10 倍。查不均不能只看 cluster slots，得结合 redis-cli --cluster check 看各槽 key 数统计，再决定要不要改 key 设计。
