Redis主从切换后短暂数据不可用，根源在于客户端连接未及时更新、新主节点AOF配置继承自旧从库（appendonly no）、客户端未主动刷新拓扑三者未对齐；需配置Lettuce拓扑刷新、预设从库AOF参数、捕获READONLY等错误即时重发现。
Redis 主从切换后发生短暂数据不可用，不是因为“切换慢”，而是客户端连接、配置继承、拓扑感知三者没对齐——旧连接还在发命令给已下线的主节点，新主节点的持久化配置未生效，客户端又没及时拿到新地址。
客户端还在用旧 master 地址发请求
哨兵或 Cluster 完成选主后，新主节点已就绪，但客户端（尤其是 Lettuce）默认不主动刷新集群拓扑。它仍拿着故障前的 master 地址重试，直到超时才报 Redis command timed out 或 MASTERDOWN。
- Lettuce 默认禁用自动拓扑刷新，需显式配置
ClusterTopologyRefreshOptions并启用enableAllAdaptiveRefreshTriggers() - Spring Boot 2.x+ 的
LettuceConnectionFactory若未设refreshPeriod（如 30s），可能卡在旧连接长达几十秒 - Jedis 虽会自动重连，但依赖
sentinel get-master-addr-by-name，若哨兵响应延迟或客户端缓存未清，也会滞后
新主节点 AOF 配置继承自从库，根本没落盘
切换后执行 INFO persistence 发现 aof_enabled:0？这不是文件损坏，是新主沿用了原从库的 appendonly no 配置。哪怕原主一直开着 AOF，只要从库配置里是 no，升主后就不写 AOF —— 所有写入只存在内存，重启即丢。
- 必须在所有从节点的
redis.conf中预设：appendonly yes、appendfsync everysec、aof-use-rdb-preamble yes -
CONFIG SET appendonly yes是临时生效，CONFIG REWRITE不会覆盖原始配置文件里的appendonly no，容器部署中尤其容易漏掉 - 验证方式：切完立刻跑
CONFIG GET appendonly和CONFIG GET appendfsync，二者都得是预期值
哨兵通知延迟 + 客户端重试策略不当放大不可用窗口
哨兵检测到故障、完成选主、通知客户端，这三步之间存在天然延迟。如果客户端在收到 READONLY 错误后盲目重试（比如重试 3 次 × 2s 超时），实际不可用时间可能被拉长到 6 秒以上。
- 哨兵的
down-after-milliseconds建议设为 5000–8000ms，failover-timeout控制在 15–30s 内，避免误判或拖太久 - 客户端应捕获
READONLY、MASTERDOWN、CLUSTERDOWN等错误，立即触发拓扑刷新，而非固定间隔重试 - 关键业务可加一层本地缓存兜底，或降级为异步写，避免因 Redis 短暂不可用直接报错
真正难处理的不是“切不切得快”，而是切完那一瞬间——谁在写、写到哪、写没落盘、客户端知不知道。这三个点里任意一个断链，都会让“短暂”变成“明显”。
