redis-cli --cluster reshard手动迁移槽位本质是「选目标、定数量、挑来源、确认执行」四步交互流程：先输槽数量（1–16384），再填接收节点完整ID，接着指定源节点（all或单个ID），最后核对plan并输入yes确认；每步出错即卡住或退出，且不可逆。
怎么用 redis-cli --cluster 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 映射，但有前提条件：
迁移完成前已建立连接的旧连接不会自动刷新映射，需等待连接池自然轮换，或手动调用 client.reloadPartitions()；
若用 redis-cli -c 测试，每次命令都是新连接，能立即生效；但业务代码里复用连接时，可能持续打错节点 1–2 分钟；
检查是否误用了 ASK 响应（迁移中）和 MOVED 响应（已切换）——只有 MOVED 才触发客户端永久更新路由表。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
什么时候该用 rebalance 而不是 reshard
rebalance 是自动计算+迁移，适合「整体偏斜但无明确目标节点」的场景；reshard 是人工指定，适合「精准补槽、扩容加节点、缩容清空某节点」：
运行 redis-cli --cluster rebalance --cluster-threshold 2 192.168.1.101:7001：表示只要节点间槽位差 > 2 个，就启动均衡，但默认只在主节点间搬，不碰从节点；--cluster-use-empty-masters 参数必须显式加，否则新加入的空 master 节点永远分不到槽；rebalance 不会跨机房/跨可用区迁移，而 reshard 可以——如果你的集群混布了不同区域节点，只能手选。
执行前必须验证的三个元数据状态
跳过这步就 run，大概率修出新问题：
检查所有节点的 cluster-enabled yes 配置是否一致，混用 cluster 模式和 standalone 模式节点会导致元数据污染；
确认没有节点残留旧的 cluster-node-timeout 设置（比如从 15000 改成 5000 后没重启），超时差异会让节点对彼此“存活”判断不一致；
用 redis-cli -c -h {node} -p {port} CLUSTER NODES 逐个查，看每个节点上报的其他节点 ID 是否全部存在、是否都标记为 master 或 slave（不能有 fail 或空状态）。
