Redis 哨兵机制

面试官问："Redis 主库挂了怎么办？"

小张说："从库接管。"

面试官追问："怎么检测主库挂了？自动切换吗？"

小张说："...用 Sentinel？"

面试官继续追问："Sentinel 是怎么选举新主库的？"

小陈答不上来。

Redis Sentinel 是 Redis 主从架构的高可用方案。这道题能说清楚 Sentinel 的故障检测、选举机制、客户端重连的候选人，对 Redis 高可用有实战理解。

一、Sentinel 架构 🔴

1.1 Sentinel 的职责

Sentinel 三大职责：
1. 监控（Monitoring）：持续监控主从库是否正常运行
2. 通知（Notification）：当故障发生时通知应用
3. 自动故障转移（Automatic Failover）：自动切换主库

1.2 Sentinel 集群

┌────────────────────────────────────────────────┐
│               Sentinel 集群（奇数个）              │
│              sentinel-1                         │
│              sentinel-2                         │
│              sentinel-3                         │
└────────────────────┬───────────────────────────┘
                     │
┌────────────────────┴───────────────────────────┐
│                    Redis 主从                   │
│   ┌──────────────┐                             │
│   │   Master     │  ← 故障检测 + 自动切换        │
│   └──────┬───────┘                             │
│          │                                       │
│   ┌──────┴───────┐                             │
│   ↓               ↓                            │
│ ┌──────┐      ┌──────┐                        │
│ │ Slave │      │ Slave│                        │
│ └──────┘      └──────┘                        │
└────────────────────────────────────────────────┘

二、故障检测机制 🔴

2.1 主观下线 vs 客观下线

-- 主观下线（SDOWN）：
-- Sentinel 认为某个实例不可达
-- 触发条件：Sentinel 向实例发送 PING，超时无响应
-- sentinel down-after-milliseconds master 5000  # 5 秒无响应

-- 客观下线（ODOWN）：
-- 超过 quorum 个 Sentinel 认为主库不可达
-- quorum 通常 = Sentinel 数量 / 2 + 1

-- 客观下线才触发故障转移

2.2 故障转移流程

-- Step 1: 选新主库（Sentinel 集群选举）
-- 条件：
-- 1. 从库和主库断开连接时间 < 指定阈值
-- 2. 复制 offset 最大（数据最新）
-- 3. run id 最小的（优先级最高）

-- Step 2: 升级选中的从库为新主库
-- SLAVEOF NO ONE  # 断开从库的从属关系

-- Step 3: 其他从库指向新主库
-- SLAVEOF new_master_ip new_master_port

-- Step 4: 旧主库重新上线后，变为新主库的从库

2.3 ❌ 错误示范

候选人原话："Sentinel 会自动检测并切换，不需要人工介入。"

问题诊断：Sentinel 本身是自动的，但客户端需要配置 Sentinel 客户端才能感知切换。如果客户端配置不当，切换后客户端仍然连接到旧主库。

【面试官心理】这道题我会从"主观下线 vs 客观下线"追问。能说清楚"为什么需要多个 Sentinel 投票确认"的候选人，说明他理解了分布式系统中的故障检测机制。

三、客户端重连 🟡

3.1 客户端配置

# Jedis 配置 Sentinel
from jedis import JedisSentinelPool

sentinel = JedisSentinelPool(
    master_name='mymaster',
    sentinels=[('sentinel1', 26379), ('sentinel2', 26379)],
    db=0
)

# 客户端自动重连：
# 1. 客户端向 Sentinel 询问当前主库地址
# 2. Sentinel 返回新主库地址
# 3. 客户端断开旧连接，连接新主库

3.2 故障转移的时序

-- 故障转移期间：
-- T1: 主库不可达，SDOWN
-- T2: 多个 Sentinel 确认，ODOWN
-- T3: Sentinel 选举 leader
-- T4: leader 执行故障转移（选新主库、切换从库）
-- T5: 故障转移完成，通知客户端

-- 整个过程：30 秒 ~ 1 分钟

四、配置建议 🟡

4.1 Sentinel 数量

# 推荐：至少 3 个 Sentinel（奇数个）
# 避免脑裂（split-brain）

# 配置：
sentinel monitor mymaster 127.0.0.1 6379 2
# mymaster：主库名称
# 127.0.0.1 6379：主库地址
# 2：quorum 数量（超过 2 个 Sentinel 确认才 ODOWN）

4.2 常见问题

-- 问题 1：脑裂
-- 主库和从库网络分区
-- Sentinel 认为主库挂了，选了新主库
-- 两个主库同时存在

-- 解决：
-- 配置 min-replicas-to-write（主库写入前确认至少 N 个从库）
min-replicas-to-write 2
min-replicas-max-lag 10  # 从库延迟超过 10 秒不允许写入

-- 问题 2：切换时间过长
-- 调整 down-after-milliseconds 和 failover-timeout
sentinel down-after-milliseconds mymaster 3000  # 3 秒检测
sentinel failover-timeout mymaster 180000  # 3 分钟超时

【面试官心理】 Sentinel 是 Redis 高可用的标准方案。能说清楚故障检测、选举机制、客户端重连的候选人，说明他对 Redis 高可用架构有实战理解。

级别	考察重点	期望回答
P5	基本职责	监控、通知、自动切换
P6	核心机制	SDOWN/ODOWN、选举机制
P7	深度问题	脑裂问题、min-replicas 配置

#Redis 哨兵机制

#一、Sentinel 架构 🔴

#1.1 Sentinel 的职责

#1.2 Sentinel 集群

#二、故障检测机制 🔴

#2.1 主观下线 vs 客观下线

#2.2 故障转移流程

#2.3 ❌ 错误示范

#三、客户端重连 🟡

#3.1 客户端配置

#3.2 故障转移的时序

#四、配置建议 🟡

#4.1 Sentinel 数量

#4.2 常见问题