java实现redis高可用需服务端、哨兵、客户端三方协同：redis配主从与≥3哨兵并配置监控参数；客户端用lettuce/jedis通过哨兵动态发现主节点；应用层控制读写分离与故障降级；上线前须验证切换闭环并监控核心指标。
Java 中使用 Redis 主从复制 + 哨兵模式实现高可用缓存，关键不是“连上就行”，而是让客户端能自动感知主节点变化、读写可控、故障时平滑切换。这需要 Redis 服务端、哨兵集群、Java 客户端三方配合，缺一不可。
Redis 侧：配好主从和至少 3 个哨兵
主从是基础，哨兵是大脑。先确保有 1 个主节点（Master）、2 个以上从节点（Replica），再部署至少 3 个哨兵实例（保障多数派决策，避免脑裂）。
- 每个从节点 redis.conf 中必须配置：replicaof
- 每个哨兵 sentinel.conf 中声明监控目标：sentinel monitor mymaster
2 - 加上认证和超时参数：sentinel auth-pass mymaster 、sentinel down-after-milliseconds mymaster 5000、sentinel failover-timeout mymaster 10000
- 启动哨兵：redis-sentinel /path/to/sentinel.conf，建议分散在不同机器上
Java 客户端：用 Lettuce 或 Jedis 连哨兵，别直连主节点
客户端不能硬编码主节点地址，必须通过哨兵动态发现当前主节点。Lettuce 更推荐（线程安全、支持响应式、自动重连机制成熟）；Jedis 需搭配 JedisSentinelPool 使用。
-
Lettuce 示例：构建 RedisURI 指向哨兵地址，再用 MasterSlave.connect() 获取连接
RedisURI sentinelUri = RedisURI.Builder.sentinel("192.168.1.11", 26379, "mymaster").withPassword("pwd").build();
StatefulRedisMasterSlaveConnectionconn = MasterSlave.connect(client, new Utf8StringCodec(), sentinelUri);
它会自动订阅哨兵的 +switch-master 事件，主节点切换后自动重连新主 -
Jedis 示例：用 JedisSentinelPool 管理连接池，每次 getResource() 返回的连接都来自当前哨兵认定的主节点
Setsentinels = Set.of("192.168.1.11:26379", "192.168.1.12:26379", "192.168.1.13:26379");
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, config, 2000, "pwd");
应用层：控制读写分离与故障降级策略
哨兵只解决“谁当主”的问题，不替你决定“怎么读”“写失败怎么办”。这部分逻辑必须由 Java 应用自己兜底。
- 写操作必须走主节点（Lettuce 的 MasterSlaveConnection 默认保证，JedisPool 也只提供主连接）
- 读操作可路由到从节点（Lettuce 支持 READFROM.REPLICA_PREFERRED；Jedis 需额外维护从节点连接池）
- 主节点临时不可用时，考虑降级方案：比如缓存穿透保护开启、短暂允许读从节点、或 fallback 到数据库（需结合业务容忍度）
- 避免在事务或 Lua 脚本中混用主从连接——哨兵切换期间可能跨节点执行，导致数据不一致
验证与可观测性：别跳过这一步
上线前必须模拟主节点宕机，验证整个流程是否闭环：哨兵是否客观下线 → 是否选出新主 → 客户端是否在 10 秒内完成重连 → 读写是否恢复正常。
- 用 redis-cli -p 26379 sentinel masters mymaster 查看当前主节点信息
- 用 redis-cli -p 26379 sentinel get-master-addr-by-name mymaster 获取实时主地址
- 在 Java 中监听 Lettuce 的 ConnectionEvents 或 Jedis 的 JedisSentinelPool 状态回调，记录切换日志
- 接入 Prometheus + Grafana，监控哨兵状态、复制延迟、连接数、failover 次数等核心指标
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
