Java应用通过Jedis或Lettuce客户端接入已部署的哨兵集群，自动发现主节点并感知故障转移；关键在于哨兵集群就绪、客户端正确配置、连接池与重试策略合理。
Java 应用本身不配置哨兵集群，而是通过支持 Sentinel 的客户端（如 Jedis 或 Lettuce）连接已部署好的哨兵系统，自动发现主节点、感知故障转移。关键在三件事：哨兵集群必须就绪、客户端正确接入、连接池与重试逻辑合理。
哨兵集群要先搭稳
这是前提，Java 端不参与选举也不判断下线，只消费哨兵提供的主节点地址。
- 至少启动 3 个哨兵进程（推荐不同机器或容器），端口如 26379/26380/26381
- 每个 sentinel.conf 配置一致，核心项包括：
sentinel monitor mymaster 192.168.1.100 6379 2（监控主节点，quorum=2 表示需 2 个哨兵同意才触发切换）
sentinel auth-pass mymaster redis123（主节点有密码时必须配）
sentinel down-after-milliseconds mymaster 5000（5 秒无响应即标记主观下线） - Redis 主从复制已稳定：主节点
role:master，从节点master_link_status:up - 哨兵日志中能看到
+monitor和+sentinel，说明哨兵彼此发现成功
Jedis 客户端接入方式
使用 JedisSentinelPool，它会在每次获取连接时向哨兵查询当前主节点，故障后自动刷新地址。
- Maven 引入（推荐 4.4.3+）：
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>4.4.3</version>
</dependency> - 初始化连接池（传入哨兵地址集合 + 主节点逻辑名）：
Set<String> sentinels = new HashSet<>();<br> sentinels.add("192.168.1.101:26379");<br> sentinels.add("192.168.1.102:26380");<br> sentinels.add("192.168.1.103:26381");<br> JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels); - 业务代码中按需取连接，用完自动归还：
try (Jedis jedis = pool.getResource()) {<br> jedis.set("key", "value");<br> System.out.println(jedis.get("key"));<br> }
故障期间可能抛出连接异常，靠外层重试或熔断兜底
Lettuce 接入更轻量且线程安全
Lettuce 原生支持异步和连接自动恢复，适合高并发场景。
立即学习“Java免费学习笔记（深入）”；
- 配置 RedisURI 指向哨兵：
RedisURI uri = RedisURI.Builder.redis("192.168.1.101")<br> .withSentinel("mymaster", "192.168.1.101", 26379)<br> .withSentinel("mymaster", "192.168.1.102", 26380)<br> .build(); - 启用自动重连与连接前探测：
ClientOptions options = ClientOptions.builder()<br> .autoReconnect(true)<br> .pingBeforeActivateConnection(true)<br> .build(); - 创建连接客户端：
RedisClient client = RedisClient.create(uri);<br> client.setOptions(options);<br> StatefulRedisConnection<String, String> connection = client.connect();
后续所有命令都基于该 connection 执行，Lettuce 内部会监听哨兵事件并自动切换主节点
让故障转移真正“无感”的细节
客户端能自动切换主节点，但业务仍可能因短暂中断失败，需配合以下策略：
- 连接池配置合理：设置
maxTotal、minIdle、testOnBorrow=true（Jedis）或启用pingBeforeActivateConnection（Lettuce） - 网络超时与重试：命令级加短超时（如 1–2 秒），失败后有限重试（建议 1–2 次），避免雪崩
- 避免长事务或大 key 操作：主从切换窗口期（通常几秒内）尽量不执行耗时操作
- 监控哨兵状态：定期检查哨兵日志中是否出现
+switch-master，确认切换是否成功完成
