Java配置Redis哨兵模式实现高可用的关键是客户端依赖哨兵动态发现主节点：一、Redis侧需稳定主从复制并部署≥3个哨兵实例；二、Java客户端用Lettuce或Jedis Sentinel Pool自动感知主变更；三、应用层需处理10–30秒故障转移延迟，配合重试、降级与事件监听。
Java 中配置 Redis 哨兵模式实现高可用故障自动转移，关键不是改 Redis 配置，而是让 Java 客户端“信任哨兵、依赖哨兵、动态连接主节点”。整个流程分三步：Redis 侧搭好主从+哨兵基础，Java 客户端用正确方式接入，应用层配合读写与降级策略。
一、Redis 侧必须先跑通主从和哨兵集群
哨兵不负责数据同步，只负责决策和通知。所以前提是主从复制已稳定运行：
- 主节点正常运行（role:master），从节点配置
replicaof <master-ip> <port>且状态为 master_link_status:up - 至少部署 3 个哨兵实例（推荐奇数），分别运行在不同机器或容器中
- 每个哨兵的
sentinel.conf包含一致配置，例如：sentinel monitor mymaster 192.168.1.100 6379 2sentinel auth-pass mymaster yourpasswordsentinel down-after-milliseconds mymaster 5000sentinel failover-timeout mymaster 10000 - 启动哨兵：
redis-sentinel /path/to/sentinel.conf，日志中出现+sentinel和+sdown/+odown表示集群已协同工作
二、Java 客户端必须通过哨兵发现主节点
硬编码主节点地址（如 192.168.1.100:6379）会彻底绕过哨兵机制，故障时完全失效。正确做法是交由客户端 SDK 自动感知主变更：
-
Lettuce（推荐）：线程安全、支持响应式、内置自动重连与主从切换
RedisURI sentinelUri = RedisURI.Builder.sentinel("192.168.1.11", 26379, "mymaster")<br> .withPassword("yourpassword").build();RedisClient client = RedisClient.create(sentinelUri);StatefulRedisMasterSlaveConnection<String, String> conn = MasterSlave.connect(client, new Utf8StringCodec(), sentinelUri);
它会订阅哨兵事件，主节点切换后自动重连新主库 -
Jedis：需搭配池化组件，每次取连接都动态获取当前主节点
Set<String> sentinels = 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, "yourpassword");
调用pool.getResource()返回的始终是哨兵认定的主节点连接
三、应用层要适配哨兵的“非瞬时”特性
哨兵故障转移通常在 10–30 秒内完成，但不是毫秒级。应用需容忍短暂不可写，并避免把哨兵当成万能兜底：
立即学习“Java免费学习笔记（深入）”；
- 写操作只发给主节点，读操作可考虑路由到从节点（需自行控制，哨兵不干预读写分离逻辑）
- 连接初始化失败、获取资源超时、执行命令报
MASTERDOWN或READONLY错误时，应触发重试或降级（如走 DB 查询） - 不要在代码里缓存主节点 IP —— Lettuce/Jedis 内部已做刷新，手动缓存反而导致 stale connection
- 生产环境建议开启哨兵事件监听（如 Lettuce 的
PubSubConnection订阅+switch-master），用于打点、告警或触发本地缓存清空
不复杂但容易忽略：哨兵本身无状态、不存数据，它的可靠性完全取决于部署规模与网络稳定性。只要主从链路通、哨兵集群能达成多数共识、客户端走对 API，故障转移就能自动发生，业务几乎无感。
