新节点加入后默认不承担任何slot，cluster meet仅建立连接而不触发迁移；必须显式执行reshard或setslot三步原子操作并确保客户端及时刷新slot缓存，否则流量仍集中于旧节点。
新节点加进去默认是空的，不自动分担流量——必须手动触发槽迁移，否则扩容等于白扩。
为什么新节点始终收不到请求
CLUSTER MEET 只建立节点连接，不分配 slot；新节点加入后 CLUSTER NODES 显示 role:master 但 CLUSTER SLOTS 查不到它负责任何 slot。客户端仍按旧拓扑路由，所有请求打到老节点，新节点 CPU 和内存长期为 0。
- 检查方式：
redis-cli -c -p 6379 CLUSTER SLOTS | grep -A 1 "your-new-node-id"，若无输出，说明未承载 slot - 根本原因：Redis Cluster 没有“自动 rebalance”逻辑，所谓“动态扩容”是误传
- 常见错觉：看到
redis-cli --cluster add-node成功就以为完事了
手动重分片三步缺一不可
用 redis-cli --cluster reshard 看似方便，但生产环境容易卡在中间状态，导致部分 slot 处于 migrating/importing 卡死，客户端反复收到 ASK 或 MOVED 错误。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 必须按顺序执行原子操作链：
① 对目标节点执行CLUSTER SETSLOT {slot} IMPORTING {source-node-id}
② 对源节点执行CLUSTER SETSLOT {slot} MIGRATING {target-node-id}
③ 迁完后对**所有主节点**广播CLUSTER SETSLOT {slot} NODE {target-node-id} - 漏掉第③步：客户端持续收到 MOVED，重定向开销翻倍，QPS 下降明显
- 顺序颠倒（比如先设 NODE）：键查不到，直接返回 (error) NOKEY 或 ERR no such key
避免迁移过程引发热点或失败
redis-cli --cluster reshard 默认“平均分配”，但实际节点负载差异大，盲目迁移反而恶化性能。
- 迁移前先查各节点内存水位：
redis-cli -p 6379 INFO memory | grep used_memory_human，避开已超 85% 的节点作为源 - 显式指定源节点：
--cluster-from {node-id}，别依赖自动选择 - 目标节点需提前清空：
redis-cli -p 6380 FLUSHALL，否则迁移中途报ERR Target node is not empty且无明确提示 - 网络延迟高时，临时调大
cluster-node-timeout（如设为 30000），防止迁移中误判 failover
客户端缓存过期导致持续重定向
即使服务端 slot 迁移完成，redis-py 的 RedisCluster 实例默认不会主动刷新 slots map，仍按旧映射发请求，造成大量额外 RTT。
- 触发刷新：客户端收到
MOVED响应后才更新本地缓存，所以第一批请求必然重定向 - 缓解方式：在迁移前主动调用
client.nodes_manager.refresh_table()（redis-py 4.7+），或重启客户端进程 - 更稳妥做法：配合
redis-cli --cluster check验证后，滚动重启应用，避免缓存 stale
真正影响平衡效果的，往往不是迁移命令本身，而是迁移前后对 slot 分布、节点水位和客户端缓存的联动判断——这三个环节任意一个脱节，都会让新节点长期闲置，集群整体吞吐卡在旧瓶颈上。
