1. Sentinel 在非集群模式的定位

一句话：在单主多从架构中，用 Sentinel 替你盯哨——探测故障、选举新主、通知客户端。

核心四职能：

职能	作用点
Monitoring	定时 PING 主从，自身也互相探测
Notification	通过日志/PubSub/外部调用报警
Automatic Failover	ODOWN→投票→复位→新主上线
Configuration Provider	客户端调用 SENTINEL get-master-addr-by-name 获取实时主节点

2. Sentinel × Redis 的一致性模型

• SDOWN：单个 Sentinel 主观判断节点挂了
• ODOWN：≥ quorum 个 Sentinel 一致认定 → 触发选举
• 选举：需获得 多数派 授权（≥ ⌈N/2⌉），否则不切换（防止脑裂）
• 配置纪元（epoch）：每次切换都会加 1，保证最终只有“最新纪元”版本存活 → 所有 Sentinel 自动收敛

结论：Sentinel 提供 最终一致，写丢失窗口取决于异步复制加上网络分区时长，可用 min-replicas-* 做上限控制。

3. 最小可行部署（MCR = Master / Clone Replica）

3.1 经典“三箱三哨”

┌─────────┐   ┌─────────┐   ┌─────────┐
│ M1 + S1 │───│ R2 + S2 │───│ R3 + S3 │
└─────────┘   └─────────┘   └─────────┘
quorum = 2

• 容忍 1 台机器或 1 个 Sentinel 宕机
• 客户端须配置 所有 Sentinel 地址，建议连接池轮询

3.2 五节点增强 & 跨 AZ

• 3 × Redis（1 主 2 从）+ 5 × Sentinel
• quorum = 3 -> 允许 2 台 Sentinel 挂掉
• 建议 “2 主机 + 1 从机” 在不同可用区，提高容灾级别

4. sentinel.conf 常用参数拆解

指令	说明 & 推荐
sentinel monitor <name> <ip> <port> <quorum>	监控主；名字唯一
sentinel down-after-milliseconds	建议 5 ~ 10 s（视网络 RTT）
sentinel failover-timeout	默认为 3 min；影响重新选主冷却期
sentinel parallel-syncs	建议 1 或 2，避免同步洪峰
sentinel announce-ip / announce-port	Docker/NAT 必配，否则自动发现失效
sentinel auth-user / auth-pass	Redis >= 6 ACL 模式专用
resolve-hostnames / announce-hostnames	若需 TLS + SAN 校验，可开启

启动：redis-server sentinel.conf --sentinel（不带 conf 会拒绝启动）

5. 故障检测 & 自动切换流程

• Replica 选择策略：replica-priority 最小 > offset 最大 > runid 字典序
• TILT 模式：当系统时钟漂移或事件循环堵塞 > 2 s，通过 30 s“冷静期”保护错判

6. 客户端实战

// Lettuce 示例
RedisClient client = RedisClient.create();
StatefulRedisConnection<String, String> conn =client.connect(RedisURI.Builder.sentinel("10.0.0.1", 26379).withSentinel("10.0.0.2", 26379).withSentinel("10.0.0.3", 26379).withSentinelMasterId("mymaster").build());

• 超时：设置 readTimeout ≥ down-after-milliseconds
• 自动刷新：Lettuce/Redisson 有内置监听 +switch-master 事件

7. Docker / NAT 注意事项

症状	根因	解决
Sentinel 互联失败	26379 被映射	--net host 或 announce-port
Replica 列表 IP 错误	内部 IP 暴露	replica-announce-ip 指定外部可达地址

8. 安全加固（ACL vs requirepass）

场景	Sentinel → Redis	客户端 → Sentinel
ACL 推荐	sentinel auth-user/-pass 指定 sentinel-user	给 Sentinel 创建最小权限用户（只允许 PING/INFO/SENTINEL …）
老版本	sentinel auth-pass <mymaster> pwd	requirepass pwd；客户端需先 AUTH

9. 运行时调参 & 扩缩容

# 新增监控
SENTINEL MONITOR orders 10.0.0.8 6379 3# 修改 down-after 毫秒
SENTINEL SET mymaster down-after-milliseconds 8000# 移除异常 Sentinel
SENTINEL RESET *

温馨提示：改动需在 所有 Sentinel 上同步执行，否则纪元不一致会导致短暂混乱。

10. 常见问题速查

现象	排查指令	解决方案
频繁切主	SENTINEL master mymaster 查看 last-ping-reply	调大 down-after-milliseconds；排查网络抖动
切主成功客户端依旧连旧 IP	检查客户端库是否监听 +switch-master	升级/开启 Sentinel 模式
Docker 集群 failover 失败	+sentinel 日志缺失	announce-ip/port 配置错误
写丢失	比对 offset	开启 min-replicas-*、业务侧做重试

结语

Redis Sentinel 为单主多从提供了“开箱即用”的 HA 能力，但也引入了一定的复杂度（最终一致、多节点配置同步等）。在 关键业务 场景中，务必：

1. 三哨起步，跨故障域部署
2. 加 ACL / TLS / 防火墙 做多层防护
3. 定期在预生产 演练 failover，验证应用与运维链路可用
4. 用 min-replicas-to-write 将数据丢失窗口限制在可接受范围

这样才能真正发挥 Sentinel 的价值，而不是在凌晨三点被“惊喜”叫醒。