不能只靠增加重试次数来“解决”该错误，它本质是集群状态或客户端行为异常的信号；盲目调高 maxRedirections 会掩盖问题、放大风险，合理值为3～5，上限不建议超8。
直接结论：不能只靠增加重试次数来“解决”这个错误，它本质是集群状态或客户端行为异常的信号，盲目调高 maxRedirections 只会掩盖问题、放大风险。
为什么单纯调大 maxRedirections 是危险操作
这个参数不是“容错开关”，而是最后的安全阀。Jedis 默认值为 5（部分旧版是 16），redis-py 4.0+ 默认是 16，ioredis 默认也是 16——这些数字都经过权衡：太小（如设为 1）会让正常槽迁移失败；太大（如设成 100）则可能让客户端在节点失联、网络分区、拓扑错乱时持续空转数十秒，拖垮线程池甚至引发雪崩。
常见误判场景：
- 把
JedisClusterMaxRedirectionsException当作“偶尔抖动”，调高maxRedirections后看似不报错了，但请求延迟飙升到几百毫秒甚至超时 - 集群正在做槽迁移，客户端却因缓存过期拓扑反复打到未接管完成的节点，重试次数拉满后才失败，实际已浪费 5 次无效 round-trip
- 某节点 TCP backlog 满（比如执行了
HGETALL大 key），拒绝新连接，客户端误判为“该节点不可用”，随机换节点重试，结果又被MOVED打回，形成死循环
maxRedirections 的合理取值范围与设置方式
安全起点是 3～5，上限不建议超过 8。具体取决于你的集群稳定性与运维节奏：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 生产环境长期稳定、极少人工干预槽位 → 设为
3即可，早暴露问题比晚失败更可控 - 有定期分片扩容/缩容计划 → 设为
5，覆盖迁移中短暂双写窗口 - 测试环境验证迁移逻辑 → 可临时设为
8，但必须配合监控确认是否真触发了多次重定向
各客户端设置示例：
Java（Jedis）： JedisCluster jc = new JedisCluster(nodes, 2000, 2000, 5, password); // 第5个参数是 maxRedirections // 或使用 builder（Jedis 4.0+） JedisPoolConfig poolConfig = new JedisPoolConfig(); JedisCluster jc = new JedisCluster(nodes, poolConfig, 2000, 2000, 5, password);
Python（redis-py）：
from redis.cluster import RedisCluster
rc = RedisCluster(
startup_nodes=[{"host": "192.168.1.10", "port": 7000}],
max_redirections=5,
decode_responses=True
)
Node.js（ioredis）：
const Redis = require("ioredis");
const cluster = new Redis.Cluster([
{ host: "192.168.1.10", port: 7000 },
], {
maxRedirections: 5,
});
真正要检查的，不是“能重试几次”，而是“为什么总要重试”
每次重定向都意味着一次额外网络往返 + 一次哈希计算 + 一次连接建立（若连接池未命中）。高频重定向背后往往藏着更关键的问题：
-
CLUSTER INFO中cluster_state不是ok，或cluster_slots_assigned≠ 16384 - 客户端初始化时传入的节点列表含
127.0.0.1或内网 DNS 不可达地址，导致拓扑刷新后连不上真实节点 - 集群节点
bind配置仍为127.0.0.1，但cluster-announce-ip未显式设为对外 IP，造成MOVED返回的地址无法从客户端访问 - 慢日志里存在 >100ms 的命令（如
KEYS *、大LRANGE），压满单节点 TCP 队列，触发“拒绝→重试→MOVED→再拒绝”链路
排查顺序应是：先 CLUSTER INFO 和 CLUSTER NODES 看服务端状态，再抓客户端日志看是否频繁打印 MOVED 响应，最后查慢日志和网络连通性。重试次数只是症状，不是病灶。
最容易被忽略的一点：重定向本身会触发拓扑刷新，而刷新又依赖 CLUSTER SLOTS 请求——如果此时目标节点尚未完成槽接管，它可能返回新的 MOVED，形成嵌套跳转。这不是客户端 bug，是 Redis 集群设计使然。所以，别指望靠调参绕过这个机制，得让集群自己稳下来。
