客户端未及时感知拓扑变更导致持续向旧主写入报readonly错误，需启用sentinel自动发现、刷新dns与连接池、前置角色校验、定期拓扑拉取及禁用连接复用并加强健康检查。
如果您在Redis Sentinel完成主从切换后，客户端仍持续向旧主地址发起连接并报出READONLY You can't write against a read only replica错误，则说明客户端未能及时感知拓扑变更。以下是多种可立即实施的解决方法：
一、启用并验证Sentinel自动发现机制
Spring Boot等主流框架的Redis客户端（如Lettuce、Jedis）依赖Sentinel主动推送或轮询获取新主地址，若未正确初始化或配置缺失，将长期复用旧连接。
1、确认使用的是JedisSentinelPool而非JedisPool，且构造时传入全部哨兵节点地址（至少两个），避免单点失效导致无法更新拓扑。
2、检查application.properties中是否完整配置：spring.redis.sentinel.master=mymaster、spring.redis.sentinel.nodes=192.168.1.10:26379,192.168.1.11:26379,192.168.1.12:26379。
3、在应用日志中搜索Discovered new master字样，若无该输出，说明+switch-master事件未被订阅成功，需排查哨兵间通信及客户端对__sentinel__:hello频道的监听权限。
二、强制刷新DNS与连接池缓存
DNS解析结果和连接池中的旧连接实例是导致请求持续打向旧IP的根本原因，必须打破这两层缓存。
1、设置JVM参数-Dsun.net.inetaddr.ttl=30，使Java InetAddress类每30秒刷新一次DNS缓存，避免永久性IP绑定。
2、对JedisSentinelPool，在收到+switch-master事件后，其内部会自动destroy旧连接池并重建；若未触发，可手动调用pool.destroy()再重新初始化。
3、对Lettuce客户端，确保未长期持有已关闭的StatefulRedisConnection对象；每次写操作前执行connection.sync().ping()做可用性探测，失败则调用RedisClient.connect()重建连接。
三、在业务命令前增加节点角色校验
不依赖错误返回被动响应，而是在每次写命令发出前主动确认连接节点角色，实现前置熔断。
1、向当前连接发送ROLE命令，解析返回值：若为["slave", "192.168.1.10", "6379"]格式，则表明该连接指向只读副本。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
2、立即丢弃该连接，不执行后续SET/INCR等写命令，避免触发READONLY错误。
3、为连接池中的每个连接添加lastRoleCheckAt时间戳字段，若距上次检查超过30秒，则强制重检角色，防止因心跳间隔过长导致误判。
四、配置客户端拓扑定期刷新策略
当事件监听不可靠时，周期性主动拉取最新主节点信息可作为兜底手段，避免拓扑长期滞后。
1、使用Redis CLI工具定期执行redis-cli -p 26379 sentinel get-master-addr-by-name mymaster，获取当前主节点IP与端口。
2、将该结果注入客户端连接工厂，强制更新连接目标；Spring Boot中可通过自定义RedisConnectionFactory实现动态地址替换。
3、设置定时任务每60秒执行一次刷新逻辑，但注意避免高频调用造成哨兵节点压力，建议配合指数退避机制（首次失败后等待2秒，再次失败后等待4秒）。
五、禁用连接复用并启用健康检查
底层TCP连接复用会掩盖节点角色变化，必须切断复用链路并引入实时健康反馈。
1、在Lettuce配置中设置ClientResources.builder().nettyCustomizer(...)，禁用连接池的keep-alive复用特性。
2、为每个连接配置PingCommandTimeout，启用后台周期性PING探测，超时即标记连接为不可用并从连接池剔除。
3、在RedisTemplate或ReactiveRedisTemplate封装层中，捕获READONLY异常时不进行重试，而是直接抛出特定业务异常（如MasterUnavailableException），由上层统一触发连接重建流程。
