27. 哨兵 Sentinel 高可用

第 26 章的主从复制解决了「数据冗余 + 读写分离」，但它有个短板：主节点挂了，需要人工干预——手动把一个从节点提升为主节点，再通知所有客户端改连新主节点。这个过程慢且容易出错。

哨兵（Sentinel） 就是来解决这个短板的：它是一个分布式监控系统，能自动发现主从拓扑、持续健康检查，并在主节点不可用时自动完成故障转移（failover），把某个从节点提升为新主节点，并重配置其余从节点和客户端。码上学把 Sentinel 的运作机制一次讲清。

本节目标

理解 Sentinel 的三个核心职责：监控、通知、自动故障转移。
理解主观下线（S_DOWN）与客观下线（O_DOWN），以及 quorum 的作用。
会用 sentinel.conf 配置并启动一个哨兵。
理解自动故障转移的完整流程。
知道客户端如何通过 Sentinel 发现当前主节点地址。

Sentinel 是什么

Sentinel 本身是一个特殊的 Redis 实例（运行在 26379 端口），不存储业务数据，只做监控与协调。它通常以多个实例组成集群（官方建议至少 3 个、且部署在不同机器上），目的是避免单个哨兵自己宕机或网络误判导致整个高可用失效。

Sentinel 的三个职责：

监控（Monitoring）：持续向主节点、从节点发送 PING，判断它们是否存活。
通知（Notification）：当被监控的 Redis 实例出现问题时，可通过脚本向运维系统（邮件、短信、Webhook）发告警。
自动故障转移（Automatic failover）：主节点被判为客观下线后，Sentinel 选举一个哨兵作为领导者，由它把一个从节点提升为新主节点，并重配置其他从节点去复制新主，最后通知客户端。

提示：从节点和其他哨兵会被 Sentinel 自动发现——它们通过主节点上的发布/订阅「hello」频道互相通信（gossip），所以你只需在配置里写明要监控的 master，无需手动登记 replica 和 sibling sentinel。

配置哨兵

一个最简的 sentinel.conf 只需要一行核心配置：

sentinel monitor mymaster 127.0.0.1 6379 2

各字段含义：

mymaster：被监控主节点的逻辑名字（只能含 A-z 0-9 . - _）。
127.0.0.1 6379：主节点的 IP 与端口。
2：quorum（法定人数）——至少有 2 个哨兵都认为主节点「客观下线」，才算真正下线，才允许发起故障转移。

常用调优项（均来自官方 sentinel.conf）：

# 判定实例「主观下线」的毫秒数，默认 30000（30 秒）
sentinel down-after-milliseconds mymaster 30000

# 故障转移时，每次同时向新主节点重新同步的从节点数，默认 1
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间（毫秒），默认 180000（3 分钟）
sentinel failover-timeout mymaster 180000

如果主节点开启了 ACL 或密码，还要配：

sentinel auth-pass mymaster <password>
# Redis 6+ 使用 ACL 时还可指定用户名：
# sentinel auth-user mymaster <username>

启动哨兵

两种等价启动方式：

redis-sentinel /path/to/sentinel.conf
# 或
redis-server /path/to/sentinel.conf --sentinel

启动后，Sentinel 会自动把发现的从节点、其他哨兵写入配置文件（所以配置目录需可写）。

主观下线 vs 客观下线

这是 Sentinel 最易混淆的一对概念，码上学用大白话解释：

主观下线（S_DOWN，Subjectively Down）：单个哨兵在 down-after-milliseconds 时间内连续收不到某实例的有效 PING 回复，就单方面认为它挂了。这只代表「我个人觉得它挂了」，可能只是这个哨兵到该实例的网络抖动。
客观下线（O_DOWN，Objectively Down）：当达到 quorum 数量的哨兵都报告同一主节点 S_DOWN 时，系统达成共识，判定主节点「客观下线」，才触发后续故障转移。

注意：O_DOWN 只针对主节点有意义；从节点和哨兵的 S_DOWN 不会升级为 O_DOWN，但依然会影响它们被处理的方式。

自动故障转移流程

当主节点被判定 O_DOWN 后，流程大致如下：

选举 Leader 哨兵：所有哨兵通过 Raft 风格的协商，选出一个哨兵来负责本次故障转移。只有拿到多数哨兵选票的哨兵才能当 leader，因此少数派网络分区里无法选出 leader，不会误转移。
挑选新主节点：leader 在存活的从节点中按规则挑选一个：优先复制偏移量最大（数据最新）、运行 ID 字典序较小、优先级（replica-priority）更高的从节点。
提升：对被选中的从节点执行 REPLICAOF NO ONE，使其成为新主节点。
重配置其余从节点：让其它从节点改为复制新主节点（REPLICAOF 新主）。parallel-syncs 控制同时重同步的并发数，避免瞬间压垮新主。
更新拓扑与通知：Sentinel 把新主节点地址广播给客户端；若配置了 client-reconfig-script，还会调用脚本通知应用层。

故障转移完成后，如果旧主节点重新上线，Sentinel 会把它降为从节点，让它去复制新主，数据重新对齐。

与哨兵交互：Sentinel API

客户端不应把主节点地址写死，而应通过 Sentinel 动态查询。常用命令：

127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6379"

这条命令返回当前主节点的 IP 和端口，是客户端发现主节点的标准做法。其它常用 API：

127.0.0.1:26379> SENTINEL masters
127.0.0.1:26379> SENTINEL replicas mymaster
127.0.0.1:26379> SENTINEL sentinels mymaster

主流客户端（如 Jedis、Lettuce、redis-py）都内置了 Sentinel 支持：你只提供哨兵地址列表和 master 名字，客户端会自动通过哨兵拿到主节点地址，并在故障转移后刷新连接。

告警与重配置脚本

sentinel notification-script mymaster /var/redis/notify.sh
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

notification-script：出现 WARNING 级事件（如 -sdown、-odown）时调用，用于发告警。
client-reconfig-script：故障转移导致主节点变更后调用，参数是 master-name role state from-ip from-port to-ip to-port，可用于自动更新应用配置。

注意：默认 sentinel deny-scripts-reconfig yes，禁止通过 SENTINEL SET 在运行时修改这两个脚本路径，以防安全滥用。

部署建议

奇数个哨兵：3 或 5 个，部署在相互独立的机器/可用区，避免与 Redis 节点同归于尽。
quorum 设为 (N/2 + 1) 附近：例如 3 个哨兵时 quorum=2，保证「多数派」才能决策，避免脑裂误转移。
不要混用 requirepass 与 aclfile：Sentinel 自身的认证与 Redis 服务端认证要协调好，否则哨兵之间、哨兵与 Redis 之间会握手失败。

常见误区

误区：1 个哨兵就够了。 单哨兵存在「哨兵自己挂掉就没高可用」以及「误判无法被纠正」的风险，生产必须 ≥3。
误区：O_DOWN 由单个哨兵判定。 必须达到 quorum 数量的哨兵一致同意，且故障转移还需多数哨兵选出 leader。
误区：客户端直连主节点地址即可。 故障转移后主节点地址会变，必须经由 Sentinel API 或支持 Sentinel 的客户端动态发现。

小结

Sentinel 是 Redis 官方高可用方案：监控 + 通知 + 自动故障转移。
核心配置一行 sentinel monitor <name> <ip> <port> <quorum>，quorum 决定「多少哨兵同意才算客观下线」。
S_DOWN 是单哨兵判断，O_DOWN 是多哨兵共识；故障转移需多数哨兵选举 leader 才能执行。
客户端通过 SENTINEL get-master-addr-by-name 动态发现主节点，而非写死地址。

提示：官方 redis.io 下载页另将 8.8 标注为 “Latest stable”，而 GitHub 上的最新发布 tag 为 8.10.0。Sentinel 配置项（sentinel monitor、down-after-milliseconds 等）在 8.x 中保持稳定，本文以 8.10.0 为基线版本。