Redis集群扩容需同步调整分片映射关系，否则客户端持续报MOVED错误；新节点默认无槽，须通过reshard或手动MIGRATING/IMPORTING迁移槽位，并确保客户端支持ASKING、刷新slot缓存、同步密码及ACL配置。
Redis 集群扩容不能只加节点，必须同步调整分片映射关系
为什么 CLUSTER ADDSLOTS 后客户端仍然报 MOVED 错误
新节点加入集群后，它默认不持有任何槽（slot），客户端请求命中未分配的槽时，旧节点会返回 MOVED 重定向。但若没用 redis-cli --cluster reshard 或手动执行 CLUSTER SETSLOT ... MIGRATING/IMPORTING 流程，槽的归属不会更新，重定向目标仍是空节点或错误节点。
- 必须先用
CLUSTER NODES确认新节点 ID 和状态为master且无fail标记 - reshard 过程中指定迁移的 slot 数量，不是“均匀分配”，而是按需从源节点搬出——别盲目选
all，容易导致单节点负载突增 - 迁移期间，源节点对这些 slot 的写入会返回
ASK而非MOVED，客户端必须支持ASKING命令，否则写失败
使用 redis-cli --cluster reshard 时卡在 “How many slots do you want to move”
这不是卡死，是等待你输入迁移槽数量。常见误操作是直接回车，结果被解释为 0，整个流程静默退出，看起来像卡住。
- 输入数字后必须按回车，比如想从 nodeA 迁 1000 个 slot，就输
1000 - 接着要指定接收节点 ID（不是 IP+端口），可用
CLUSTER NODES输出里第一列的 40 位字符串 - 最后选择源节点：输
all表示从所有主节点均衡搬出；输具体 ID 则只从那个节点迁——生产环境推荐后者，便于控制影响范围
扩容后出现 CROSSSLOT 或 NOAUTH 报错
这通常和客户端连接配置没同步更新有关，不是集群本身问题。
- 客户端 SDK（如 Jedis、StackExchange.Redis）若缓存了旧的 slot 映射表，重启应用或调用
refreshClusterSlots()类方法强制刷新 - 如果集群启用了密码（
requirepass），新节点配置文件里也必须有相同requirepass，否则部分客户端在重定向后连新节点会因无认证被拒，报NOAUTH -
CROSSSLOT多半是因为 pipeline 或 multi/exec 涉及多个 key，它们落在不同 slot 且跨了新旧节点——扩容不改变 key hash 规则，但 slot 分布变了，原来能同节点执行的操作现在可能跨节点，得改用hash tag（如{user1001}.profile和{user1001}.settings）强制路由到同一 slot
真正麻烦的从来不是加机器，而是 slot 迁移过程中请求抖动、客户端兼容性、以及密码/ACL 配置漏同步——这些细节不检查，扩容完立刻倒退成故障现场。
