Sentinel 是什么
Sentinel（哨兵）是 Redis 官方的高可用组件，本身是一组独立进程（默认监听 26379），不存放业务数据。它的职责有四件事：持续监控主库与从库是否可达、在判定主库失效时通过选举产生一个领导者并执行主从切换、把切换结果通知客户端或运维、以及充当配置提供者让客户端随时查到当前主库地址。哨兵集群的引入就是为了让主库单点故障不再需要人工介入。
基本信息
| 部署形态 | 独立进程，可与 Redis 同机也可分开；建议至少 3 个且为奇数 |
|---|---|
| 默认端口 | 26379 |
| 启动方式 | redis-sentinel /etc/redis/sentinel.conf，等价于 redis-server 该文件 --sentinel |
| 监控单位 | 一个 master 组，一个哨兵集群可同时监控多套主从 |
| 依赖前提 | 主从复制已经正确建立，否则切换后没有可用的新主库 |
典型使用场景
- 主从架构下需要自动故障转移，又不想承担集群模式的改造成本与多键限制
- 读多写少的中小规模业务，用哨兵提供主库地址查询，客户端按角色分发读请求
- 对客户端透明地完成主库漂移：应用启动时向哨兵问一次地址，切换后重新查询
- 多套独立主从共用一个哨兵集群做统一监控，减少运维组件数量
- 计划内维护：先手动切换主库，把原主库降级维护后再切回
启动与查询
启动与查询
redis-sentinel /etc/redis/sentinel.conf # 按配置启动一个哨兵
redis-cli -p 26379 SENTINEL MASTERS # 本哨兵监控的所有主库
redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster # 当前主库地址
redis-cli -p 26379 SENTINEL SENTINELS mymaster # 其他哨兵成员
redis-cli -p 26379 SENTINEL CKQUORUM mymaster # 票数是否够判定下线
tail -f /var/log/redis/sentinel.log # 切换过程在日志里逐条可见四类职责与观测点
| 职责 | 动作 | 查看方式 |
|---|---|---|
| 监控 | 周期性 PING 主库、从库与其他哨兵 | SENTINEL MASTER 的 last-ping-reply |
| 判定 | 主观下线 SDOWN，多哨兵确认后客观下线 ODOWN | flags 字段中的 s_down 与 o_down |
| 选举 | ODOWN 后投票选出领导者负责执行切换 | 哨兵日志中的 vote-for-leader 记录 |
| 通知与配置 | 对外提供当前主库地址并改写自身配置 | GET-MASTER-ADDR-BY-NAME 与 conf 文件 |
哨兵需要写入权限：运行过程中会把发现的从库、其他哨兵以及切换结果自动补写进配置文件。配置文件不可写时哨兵仍能启动，但发现结果无法落盘，重启后会丢失认知，切换状态可能异常。
为什么强调 3 个以上：客观下线需要达到 quorum 票数，执行切换还需要领导者选举获得哨兵总数的多数派同意。只有 1 到 2 个哨兵时，任一节点失联都可能既无法判定也无法选举，高可用形同虚设。
切换过程做了什么
- 主观下线：某个哨兵在 down-after-milliseconds 内收不到主库有效响应，把该主库标记为 s_down
- 客观下线：该哨兵向其他哨兵求证，票数达到 quorum 后主库进入 o_down，具备切换前提
- 领导者选举：愿意执行切换的哨兵参与投票，得票超过哨兵总数一半的成为领导者
- 挑选新主库：按复制偏移量与优先级等条件选出最合适从库，其余从库改为复制新主库
- 旧主库降级：原主库恢复后被哨兵识别为从库并被要求复制新主库，防止出现双主写入
哨兵与数据实例不要集中在同一台物理机上：整机宕机时会同时损失数据节点与投票节点，既没有可切换的目标，也没有足够的票数完成切换。至少把投票节点分散到三个故障域。