reshard 搬的是 Slot 而非 Key，先重分配 16384 个 Slot，再由集群自动触发 Key 迁移；需待“All keys transferred”提示才完成，且新节点须完成注册、握手、身份确认三步并满足网络与配置要求。
reshard 命令到底在搬什么？
它搬的是 Slot，不是 Key。Redis 集群扩容时，reshard 不会直接移动数据，而是把某个范围的 Slot（共 16384 个）从旧节点重新分配给新节点；Key 的迁移发生在 Slot 分配完成后，由集群自动触发 MOVE 或 ASK 重定向逻辑驱动。
常见错误现象：CLUSTER NODES 显示 Slot 已分配给新节点，但客户端仍报 MOVED 错误、请求被重定向回老节点——说明 Slot 迁移尚未真正完成，只是“计划已提交”，还没执行完数据搬运。
- 必须等
redis-cli --cluster reshard输出 “All keys transferred” 才算迁移结束 - 迁移期间，目标节点必须处于
fail? no状态，且不能是myself,master之外的角色（比如不能是 slave） - 源节点和目标节点的
cluster-enabled yes必须一致，否则reshard会静默失败
添加新 Master 节点前必须做的三件事
新节点不是加进集群就自动参与 Slot 分配的。它得先“注册”，再“握手”，最后“确认身份”。漏掉任一环，reshard 会找不到目标节点。
- 启动新节点时配置文件里必须有
cluster-enabled yes和唯一cluster-config-file - 用
redis-cli --cluster add-node <new-node><existing-node></existing-node></new-node>完成握手；注意顺序：新节点地址写前面，已有节点写后面 - 新节点默认是 master，但角色未被集群承认——需用
CLUSTER NODES检查其状态是否含master且无noaddr标记
reshard 过程中为什么卡住不动？
最常见原因是网络或权限问题导致 Key 迁移阻塞，而非命令本身出错。此时 redis-cli --cluster reshard 看似在运行，实则停在某 Slot 的搬运上。
典型错误信息：Error moving key xxx: Connection refused 或长时间无输出后超时退出。
- 检查新老节点之间 6379（服务端口）和 16379（集群总线端口）是否双向互通（很多人只开了 6379）
- 确认新节点
maxmemory设置足够，否则迁移 Key 时因内存满而拒绝接收 - 避免在迁移期间执行
FLUSHALL或大量写入，会加剧迁移延迟甚至触发超时重试失败
迁移完成后，客户端连接要不要改？
不用改连接串，也不用重启应用。Redis 集群靠客户端自己发现拓扑变更——前提是客户端支持集群协议并开启了自动刷新机制。
但容易被忽略的一点：很多老版本 Jedis、StackExchange.Redis 默认不主动拉取 CLUSTER SLOTS，得手动触发或配置刷新间隔。
- Java Jedis：需使用
JedisCluster，且构造时传入非零refreshPeriod（单位 ms），否则拓扑变更后仍发请求到旧节点 - .NET StackExchange.Redis：设置
ConnectTimeout和SyncTimeout后，它会在收到MOVED时自动更新内部 slot map，但首次发现可能慢 1–2 秒 - Python redis-py-cluster：必须调用
StrictRedisCluster.reset_cache()强制刷新，否则缓存的 slot 映射不会更新
Slot 数量固定、节点角色可变，这是集群平滑性的基础；但“平滑”不等于“无感”，客户端适配那层，往往才是线上扩容翻车的第一现场。
