根本原因是扩容时新旧节点内存双吃，迁移命令因OOM被拒导致重定向中断；须预留当前内存×1.3（≥512MB），淘汰策略必须设为allkeys-lru并调大client-output-buffer-limit与repl-backlog-size。

为什么集群扩容时会触发重定向失败？

根本原因是：扩容期间节点间数据迁移（MOVE、ASK、MOVED）本身要占用额外内存，而旧节点尚未释放已迁出的 key，新节点又在加载大量 key —— 两边同时吃内存。此时若 maxmemory 已逼近上限，noeviction 策略会让 SET 或 MIGRATE 命令直接返回 (error) OOM command not allowed when used memory > 'maxmemory'，导致重定向链路中断，客户端收不到 MOVED 响应，连接卡死或轮询失败。

必须预留多少内存才够安全？

不能只看当前 used_memory_human，得按迁移峰值预估：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 迁移一个 1MB 的 hash，实际可能临时占用 2–3MB（序列化 + 复制缓冲区 + 客户端输出缓冲区）
• Redis 集群迁移默认并发 1 个 slot，但客户端批量 MIGRATE 可能堆积多个 slot 的待迁移数据
• 建议预留空间 = 当前 used_memory × 1.3，且绝对值不低于 512MB（小实例也别低于 256MB）
• 执行前用 redis-cli --cluster check 看各节点 mem_usage，挑最高值做基准

淘汰策略选 allkeys-lru 还是 volatile-lru？

集群扩容场景下，必须选 allkeys-lru：

• volatile-lru 只淘汰带 TTL 的 key，而迁移过程中的临时 key（如 __redis__:move:xxx）、客户端连接缓冲、复制积压缓冲区都不带 TTL，无法被回收
• allkeys-lru 能覆盖所有内存对象，包括未设置过期时间的冷数据、大 value、闲置连接的输出缓冲区
• 别用 allkeys-random —— 随机删可能误杀正在被迁移的活跃 key，引发数据不一致
• 确认命令：CONFIG SET maxmemory-policy allkeys-lru，且确保 maxmemory 已设为非零值（0 表示不限制，但集群模式下不推荐）

配置后仍重定向失败？检查这三个隐藏点

淘汰策略生效 ≠ 问题自动消失，以下细节常被忽略：

• client-output-buffer-limit 设置过小：迁移中客户端响应积压，buffer 暴涨。检查 CONFIG GET client-output-buffer-limit，对 pubsub 和 slave 类型至少设为 256mb 64mb 60
• 复制积压缓冲区（repl-backlog-size）未调大：扩容期间主从同步压力大，backlog 不足会触发全量同步，瞬间吃光内存。建议从默认 1MB 改为 128mb
• 迁移命令未加 COPY 和 REPLACE：漏掉 REPLACE 会导致目标节点写入失败后反复重试，不断申请内存。正确命令形如：MIGRATE 10.0.0.2 6379 "" 0 5000 COPY REPLACE KEYS key1 key2

集群扩容不是“改完配置重启就完事”，内存水位和淘汰策略必须协同压测验证。最危险的不是内存满，而是满得刚好卡在重定向握手阶段——这时候日志里看不到明显报错，只有客户端超时和 ASKING 循环，得盯紧 INFO memory 里的 mem_fragmentation_ratio 和 evicted_keys 实时变化。