Redis哨兵模式下需通过缩短客户端哨兵轮询间隔（如设为5000ms）、配置多数派quorum防脑裂、强制失败后重查哨兵地址来快速感知拓扑变化；应用层按业务域熔断、用带TTL的本地缓存（如Caffeine）、写请求异步化，并禁用min-replicas-to-write宽松配置以避免分区写入。
Redis哨兵模式下如何检测并自动恢复网络分区
网络分区发生时，客户端可能还在往“逻辑主节点”发请求，但该节点实际已失联——这不是缓存失效问题，而是服务发现失效。关键不是等超时，而是让客户端立刻感知拓扑变化。
-
redis.FailoverClient（Go）或JedisSentinelPool（Java）这类客户端会定期向哨兵拉取主节点地址，但默认轮询间隔是 30 秒，太慢；建议显式配置sentinelMonitorInterval或sentinelCheckInterval为5000毫秒 - 哨兵自身也要防脑裂：确保
quorum值设为多数派（如 3 个哨兵就设2），避免单点误判导致频繁主从切换 - 客户端连接失败后不能立即重试原地址，必须强制触发一次哨兵查询；否则可能卡在旧主节点的 DNS 缓存或连接池里
应用层怎么绕过不可用的Redis集群继续提供服务
网络分区 ≠ 所有 Redis 节点全挂，但客户端可能因连接超时或读写失败直接报错。这时降级不是“要不要做”，而是“以什么粒度做”。
- 别全局开关降级——按业务域隔离：
user:profile失效时不影响order:list，用不同熔断器实例分别控制 - 本地缓存不能简单用
ConcurrentHashMap，得带 TTL 和主动刷新能力；推荐Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES)，避免脏数据长期滞留 - 数据库查完后，不直接写回 Redis（可能仍分区中），而是投递到异步队列（如 Kafka），由独立消费者在分区恢复后再批量回填
为什么AOF重放无法解决网络分区后的数据不一致
AOF 是持久化手段，不是一致性协议。网络分区期间，旧主节点若继续接受写请求（即出现“脑裂”），AOF 日志会记录这些操作，但新主选举后这些日志不会被同步或回滚。
- 必须关闭
min-replicas-to-write的宽松配置，生产环境应设为1以上，确保主节点只有在至少一个从节点在线时才接受写入 - 分区恢复后，旧主降级为从时会执行
slaveof同步，但此时它自己的 AOF 可能含冲突写入；Redis 不会自动清理，需人工检查INFO replication中的master_replid是否一致 - 更稳妥的做法是：分区期间所有写请求走
readonly模式，并记录到本地 WAL，待分区确认结束再重放——这需要业务代码配合，不是 Redis 自身能兜底的
监控指标里最容易被忽略的“假健康”信号
集群节点存活数、CPU、内存都正常，不代表没分区。真正危险的是“半联通”状态：客户端能连上哨兵，也能连上某个 Redis 实例，但该实例和其余节点之间 TCP 连接已中断。
- 必须监控
connected_slaves（主节点视角）和master_link_status:up（从节点视角）两个指标，二者不一致就是分区苗头 - 哨兵日志里要盯
+sdown和+odown事件，+sdown是单哨兵判定，+odown才是多数派共识；只看到前者就切主，大概率误操作 -
redis-cli -c -h sentinel-host -p 26379 SENTINEL get-master-addr-by-name mymaster这条命令每分钟跑一次，比依赖客户端 SDK 的内部逻辑更可信
