哨兵事件怎么用
哨兵把状态变化以事件形式发布到自己的发布订阅频道，客户端订阅后能在主库地址变化的第一时间刷新连接，也能把事件接进告警系统。同样的内容会写进哨兵日志，线上排障通常用日志做时间线、用事件做自动联动。
基本信息
| 订阅方式 | 连接哨兵端口（默认 26379）执行 SUBSCRIBE 或 PSUBSCRIBE |
|---|---|
| 关键事件 | +switch-master、+sdown、+odown、+failover-end、+new-epoch |
| 哨兵间频道 | __sentinel__:hello，用于哨兵互相发现 |
| 为什么用 | 客户端刷新主库地址、告警联动、演练时间线核对 |
典型使用场景
- 客户端刷新主库地址：收到 +switch-master 后重建连接池，减少写入失败窗口
- 告警联动：把 +odown 与 +switch-master 接入监控，人工介入前先有通知
- 演练核对：用事件顺序确认切换只选举了一次、有没有反复尝试
- 排查误判：对比多台哨兵报出的 +sdown 时间，判断是网络分区还是目标真的挂了
- 确认哨兵间沟通正常：观察 hello 消息是否持续更新，判断是否有哨兵掉队
订阅示例
订阅示例
redis-cli -p 26379 PSUBSCRIBE '*' # 排障时订阅全部哨兵事件
redis-cli -p 26379 SUBSCRIBE +switch-master # 只关心主库切换
# 切换后收到的消息结构：pmessage / 匹配模式 / +switch-master / 'mymaster 旧IP 旧端口 新IP 新端口'
redis-cli -p 26379 PSUBSCRIBE '__sentinel__:hello' # 观察哨兵之间的问候消息
grep -E 'switch-master|sdown|odown' /var/log/redis/sentinel.log | tail -20 # 日志对照关键事件读法
| 事件 | 触发时机 | 处理建议 |
|---|---|---|
| +sdown / -sdown | 单台哨兵的主观下线判定与恢复 | 只看一台报 sdown 时先怀疑网络 |
| +odown / -odown | 达到法定票数的客观下线 | 通常紧接着进入切换流程 |
| +try-failover / +elected-leader | 开始尝试切换与选出执行切换的哨兵 | 确认只选举了一次 |
| +switch-master | 新主库地址确定 | 立即刷新客户端连接并更新入口 |
| +failover-end | 切换流程结束 | 核对其余从库是否已重指向 |
| +new-epoch | 配置纪元递增 | 用于过滤过期事件，避免重复处理 |
+switch-master 的消息体是空格分隔的固定字段：主库名、旧地址、旧端口、新地址、新端口，按位置解析即可，不要依赖会变化的文本前缀。
__sentinel__:hello 频道承载哨兵之间的互相发现，消息里包含发送方哨兵地址、运行 id、当前纪元以及它认知的主库地址；客户端也可以借这个频道发现其他哨兵。
事件是异步通知而不是可靠投递：订阅连接断开期间的事件不会补发。关键路径必须以查询结果为准，例如拿到事件后再用 SENTINEL get-master-addr-by-name 确认当前主库地址。