应用侧无感知的关键在于客户端自动适配新主节点，核心是解耦地址绑定、建立变更通知与重连机制；采用哨兵模式、订阅+switch-master事件、写失败柔性处理，并须经真实切换验证。
应用侧无感知的关键不在于“不发生切换”，而在于让客户端自动适配新主节点，避免重启、改配置、丢请求。核心是解耦客户端与固定主节点地址的绑定关系，并建立可靠的变更通知与重连机制。
用哨兵模式替代硬编码地址
客户端不再直连某个IP:Port，而是连接哨兵集群，由哨兵动态返回当前主节点地址。主流客户端（如Lettuce、Jedis Sentinel Pool、Redisson）原生支持该模式：
- Jedis通过
JedisSentinelPool初始化，传入哨兵地址列表和master name，后续所有写操作自动路由到哨兵告知的主节点； - Lettuce使用
RedisSentinelConfiguration，支持自动监听+switch-master事件并刷新连接； - 配置中必须确保
sentinel monitor定义的master name与客户端代码中使用的名称完全一致。
订阅哨兵的主节点变更通知
哨兵在完成故障转移后，会向__sentinel__:hello频道发布+switch-master事件，包含旧主、新主的IP和端口。客户端应主动订阅该频道：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Java可用Lettuce的
StatefulRedisConnection监听RedisNodeDescription变更； - Python可用redis-py的
pubsub模块订阅__sentinel__:hello，解析事件内容更新连接池； - 即使错过一次通知，也要配合定期轮询哨兵（
SENTINEL get-master-addr-by-name）兜底，避免长期失联。
写请求失败时做柔性处理
哨兵选举+客户端感知存在毫秒级窗口，期间写请求可能失败。不能直接抛异常，需设计缓冲层：
- 对非强一致性写操作（如日志、统计类），可先写入本地队列或Kafka，由后台消费者重试；
- 对关键写操作（如订单、扣款），应用层捕获
RedisConnectionException或MasterDownException，暂停写入并触发主动探活，待新主就绪后再恢复； - 连接池需配置合理的超时（connect timeout、socket timeout）和最大重试次数，避免阻塞线程。
验证与压测不可跳过
无感知不是默认效果，必须验证真实切换场景下的行为：
- 模拟主节点宕机（
kill -9或网络隔离），观察客户端日志是否出现重连、是否收到switch-master事件； - 检查切换前后写入数据是否连续（如递增key），确认无丢失或重复；
- 压测时注入随机主从切换，验证P99写延迟是否稳定，错误率是否趋近于0。
