Sentinel哨兵监控详细解析，写得太好了，建议收藏！

Sentinel哨兵是Redis提供的高可用性解决方案，用于解决主从复制架构中主节点宕机后需要手动切换的问题。通过自动化监控和故障转移机制，Sentinel显著提升了Redis集群的可用性。

• 监控：Sentinel进程持续检查主从服务器的运行状态，通过发送命令并等待响应判断节点是否存活。
• 提醒：当检测到节点异常时，Sentinel可通过API向管理员或应用程序发送通知（如邮件、短信等）。
• 自动故障转移：主节点宕机时，Sentinel自动从从节点中选举新主节点，并更新其他从节点的配置，同时向客户端返回新主节点地址。

为避免单点误判，Sentinel采用多哨兵协同工作模式，并定义了两种下线状态：

• 主观下线（SDOWN）单个Sentinel在指定时间内（down-after-milliseconds配置）未收到节点响应，即认为该节点主观下线。可能因网络问题导致误判。

• 客观下线（ODOWN）多个Sentinel通过SENTINEL is-master-down-by-addr命令交换信息，当足够数量的Sentinel（仲裁值quorum）均认为主节点主观下线时，判定为客观下线。

  仲裁值（quorum）：通常设置为Sentinel数量/2 + 1（如3个Sentinel时设为2）。

1. 配置文件准备创建3个Sentinel配置文件（如sentinel-1.conf），核心参数如下：

   port 26379 # 哨兵端口bind 0.0.0.0 # 允许所有IP访问daemonize yes # 后台运行sentinel monitor mymaster 8.129.113.233 6379 2 # 监控主节点，quorum=2sentinel down-after-milliseconds mymaster 5000 # 5秒无响应视为主观下线sentinel auth-pass mymaster 123456 # Redis密码sentinel failover-timeout mymaster 30000 # 故障转移超时时间

2. 启动顺序按主节点 → 从节点 → Sentinel的顺序启动服务，确保依赖关系正确。

3. 启动命令

   ./redis-server /path/to/sentinel-1.conf --sentinel./redis-server /path/to/sentinel-2.conf --sentinel./redis-server /path/to/sentinel-3.conf --sentinel

4. 日志目录提前创建/var/log/redis目录用于存储哨兵日志。

1. 主节点宕机：Sentinel检测到主节点无响应，标记为SDOWN。
2. 仲裁投票：其他Sentinel确认主节点SDOWN后，达成ODOWN共识。
3. 选举新主节点：从从节点中选举优先级最高（或数据最完整）的节点晋升为主节点。
4. 更新配置：新主节点通知其他从节点复制自身，并修改客户端连接地址。

日志关键阶段：

• +sdown：主观下线通知。
• +odown：客观下线确认。
• +switch-master：主节点切换完成。

在application.yml中配置哨兵集群地址，替代单节点配置：

优势：

• 客户端自动感知主节点变化，无需重启服务。
• 支持读写分离（主写从读）。

• 优点：

  高可用性：主从自动切换，服务中断时间极短。

  去中心化：无单点故障，哨兵集群协同工作。

  配置简单：通过少量参数即可实现复杂的高可用逻辑。

• 缺点：

  主节点性能受限：所有写操作集中于主节点，无法横向扩展。

  集群规模限制：Sentinel适合中小规模集群，大规模场景需考虑Redis Cluster。

  脑裂风险：网络分区可能导致多个主节点并存（需通过min-slaves-to-write等参数缓解）。

1. 哨兵数量：建议部署3个或以上奇数个哨兵，确保仲裁可靠性。
2. 资源隔离：哨兵节点应与数据节点物理隔离，避免资源竞争。
3. 监控告警：集成Prometheus等工具监控Sentinel状态，及时处理异常。
4. 测试验证：定期模拟主节点故障，验证故障转移流程是否符合预期。

通过合理配置Sentinel哨兵，可显著提升Redis集群的可用性，但需根据业务场景权衡性能与一致性需求。对于超大规模集群，建议进一步评估Redis Cluster方案。