Redis集群扩容：reshard迁移Slot添加节点

Redis集群在线扩容的核心在于通过reshard命令精准重分配16384个Slot（而非直接搬运Key），由集群在Slot归属变更后自动触发Key迁移；整个过程需严格满足新节点“注册—握手—身份确认”三步流程、网络端口双向互通、内存充足及配置一致等前提，且必须等待“ALL keys transferred”提示才代表真正完成——任何环节疏漏（如客户端未启用拓扑自动刷新）都可能导致MOVED重定向失败、请求持续打到旧节点，让看似平滑的扩容在线上真实环境中悄然翻车。

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 完成握手；注意顺序：新节点地址写前面，已有节点写后面
• 新节点默认是 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 数量固定、节点角色可变，这是集群平滑性的基础；但“平滑”不等于“无感”，客户端适配那层，往往才是线上扩容翻车的第一现场。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。