redis集群故障切换“自动”指内部主从切换，“透明”取决于客户端是否处理moved/ask重定向；jedis默认抛clusterredirectexception，lettuce默认自动重试一次；jediscluster需配置maxredirections=5、初始化传全节点、捕获异常后flushnodecache并重试，且cluster-node-timeout不宜过小（建议≥10秒）以防误切。
Redis 集群本身不提供“透明”故障切换——客户端必须能处理 MOVED 或 ASK 重定向，否则会报错。所谓“自动”，是集群内部完成主从切换；所谓“透明”，取决于客户端是否支持重试与拓扑刷新。
为什么 Java 客户端调用会抛出 ClusterRedirectException？
这不是 bug，而是集群协议的正常反馈。当主节点宕机、从节点刚晋升为新主时，旧客户端缓存的 slot 路由仍指向已下线节点，首次请求就会收到 MOVED 响应，Jedis/Lettuce 默认不自动重试该命令。
-
MOVED表示 slot 已永久迁移到新节点（如MOVED 1234 127.0.0.1:7004） -
ASK表示临时迁移中，需先向目标节点发ASKING再执行命令 - Jedis 默认抛
ClusterRedirectException；Lettuce 默认自动重试一次（可配置）
如何让 JedisCluster 实现接近“无感”的切换？
关键不是等客户端“自动修复”，而是提前规避或快速响应重定向。以下配置和调用方式缺一不可：
- 初始化时传入全部节点（不只是 startup nodes），避免冷启动路由缺失
- 设置
maxRedirections=5（默认 5，够用但别设过大，防环路） - 写操作务必用
try-catch捕获ClusterRedirectException，手动重试或退避 - 避免长期复用单个
JedisCluster实例——它内部缓存 topology，故障后可能 stale；建议配合连接池或定期 refresh
示例片段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
try {
jedisCluster.set("key", "val");
} catch (JedisClusterException e) {
if (e.getCause() instanceof ClusterRedirectException) {
// 触发 topology 刷新（Jedis 内部会尝试 ping 所有节点）
jedisCluster.flushNodeCache();
// 业务层重试，或交给上层重试机制
}
}
cluster-node-timeout 设太小会导致频繁误切吗？
会，而且后果严重。这个参数不是“越快越好”，它是故障判定的唯一时间标尺：
- 默认
15000（15 秒），生产环境建议 ≥ 10 秒 - 若设为
3000，短暂网络抖动（如 GC STW、交换页延迟）就可能触发主观下线 → 多数节点投票 → 客观下线 → 选举新主 → slot 迁移 → 客户端大面积MOVED - 真正影响 RTO 的不是 timeout 本身，而是复制偏移量追赶时间。确保从节点
repl-backlog-size足够大（至少能覆盖 timeout 窗口内的写量）
客户端无法感知切换完成？检查这几个点
集群切换完成 ≠ 客户端立刻可用。常见卡点在客户端侧：
- 未启用
pingBeforeActivateConnection（Lettuce）或testOnBorrow（Jedis），导致连接池里残留失效连接 - 应用层 DNS 缓存或 host 绑定（如硬编码
127.0.0.1:7001），绕过了集群发现逻辑 - 使用了非集群客户端（如普通
Jedis）直连某个节点，完全不走 slot 路由 - 客户端版本过旧（如 Jedis CLUSTER NODES 解析有 bug，无法正确识别新主节点状态
最稳妥的做法：所有客户端必须用官方推荐的集群模式驱动（JedisCluster / LettuceClusterClient），且禁用任何直连逻辑。真正的“透明”只存在于协议层，不在客户端代码里硬扛。
