怎么说呢，

在实际业务中，主节点宕机后写入能力瞬间消失导致程序不可用。这正是大多数使用者面对 Redis 高可用时的首要痛点。

哨兵节点本质也是 Redis 实例。通常由多台机器组成集群，生产环境至少部署 3 台。说起来，

它承担三大职责：

1️⃣ 监控

持续探活主从节点。确保它们处于正常工作状态。

2️⃣ 自动故障恢复

当主节点挂掉时哨兵会挑选一个从节点提高为新的 Master；从节点挂掉时会自动将其剔除。怎么说呢，

3️⃣ 通知客户端

客户端通过 Sentinel 获取当前 Master 地址。Master 切换后能够自动发现新的服务入口。怎么说呢，

这三件事合起来就是 Redis 主从高可用的根本保障。也是解决“写入失效”痛点的关键。

哨兵是怎么盯哨的

哨兵采用心跳机制判断服务生死，默认每 1 秒 向集群每个实例发送一次 PING。

收到 PONG 即视为实例正常；若在限定时间内未收到响应，单台哨兵会做出“主观下线”。

注意：主观下线仅是该哨兵的个人判断。要形成客观下线，需要其他哨兵一起投票。

当认为节点下线的哨兵数量达到 quorum 阈值时才会标记为客观下线.

User Pain Point： 如果 quorum 配置不合理。即使少数哨兵误判，也可能导致不必要的故障切换，引发业务波动。

主节点挂了哨兵怎么选新主

1. 过滤长时间断开的从节点：断连时间超过配置阈值的从节点直接失去候选资格，以防数据丢失过多。
2. 比较优先级：# sentinel-priority ,值越小优先级越高。
3. 比较复制偏移量： 可以优先考虑复制偏移量最大的从节点，因为它的数据最完整、最接近原主节点。
4. Tiebreaker – run id： 只有前面条件全部相同才会依据随机的 run id 决定。

User Pain Point： 如果没有正确设置 # min-replicas-to-write/# min-replicas-max-lag。新旧 Master 可能都接受写请求，导致数据不一致或丢失。老实说，

脑裂的观点是。 一个大脑裂成两个

场景描述：

• A 区域的 Master 与 Sentinel 被网络切分到不同分区，Sentinel 只能看到从节点。
• Senti nel 按选主规则把其中一个从节点提高为新 Master。
• A 区域的原 Master 实际并未宕机。只是网络不可达，仍然接受客户端写入。
• 此时出现“双 Master”，即简单讲“脑裂”。

User Pain Point：

• 写入数据丢失：C 端仍向原 Master 写入，而新 Master 无法同步这些数据。网络恢复后原 Master 被降级为从库，同步过程会清空其在脑裂期间写入的数据。
• C 端可能因为两套 Master 的冲突产生异常错误或超时。

脑裂怎么治

SENTINEL 提供两项关键配置即可大幅降低脑裂风险：

#1 min‑replicas‑to‑write>= 1

The master will only accept write requests if at least this many replicas are online.

#2 min‑replicas‑max‑lag

If any replica’s replication lag exceeds this threshold。master will reject writes.

• If a network partition occurs,isolated master will instantly refuse writes because it cannot see enough healthy replicas.
• This prevents large amounts of data from being written into an “island”,eliminating massive data loss after reconnection.

再看面试实战，三连问

‼ 问：怎么保证 Redis 的高可用？

• SENTINEL 模式：监控、自动故障恢复、通知客户端三个主要功能，实现无感知切换。其实，

‼ 问：你们 Redis 是单点还是集群？用哪种集群，

• Simplest solution: 一主一从 + Sentinel 已能满足大多数业务对高并发和高可用的需求。怎么说呢，

• SINGLE MASTER: 写入口；SLE: 读压力均衡，单实例通常能支撑 10K~100K QPS。

• If 数据量>10GB。可拆分多套主从，实现水平扩容。

‼ 问：Redis 集群脑裂怎么解决？

• 阐述脑裂根源的观点是。网络分区导致 Sentinels 将旧 master 错误降级/提高，从而出现双 master。
• 主要方法这方面，配置 min-replicas-to-write 和 min-replicas-max-lag。让孤岛 master 在无法确认足够副本同步时拒绝写请求，从根本上阻止数据写进孤立区域。
• 额外措施这方面。合理设置 quorum、sentinel down-after-milliseconds 与 failover-timeout，以降低误判概率。

通过上述机制。你可以把 “Redis 主从宕机即失去写入能力” 和 “脑裂导致的数据丢失” 两大痛点转化为“只要满足最小副本数量且延迟在阈值内，就始终保持可写&一致”的可靠服务体验。