Redis 主从切换怎么保证应用侧无感知

应用侧无感知的关键在于客户端自动适配新主节点，核心是解耦地址绑定、建立变更通知与重连机制；采用哨兵模式、订阅+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和端口。客户端应主动订阅该频道：

• 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。