Redis哨兵（Sentinel）通过监控主从节点的心跳检测故障，实现自动故障转移保障高可用，配置时需注意哨兵监听端口、从节点信息及quorum参数避免常见脑裂问题。

Redis哨兵进程原理与高可用保障机制

Redis Sentinel是一个Redis的高可用性解决方案，它是一个独立的进程，用于监控Redis主从节点，并在主节点故障时自动进行故障转移（failover），将某个从节点提升为主节点，从而实现Redis的高可用。

Sentinel的工作原理是通过发送PING命令定期检查Redis实例是否存活，如果主节点长时间未响应，多个Sentinel进程会通过投票机制达成共识，启动故障转移流程。

高可用保障依赖于Sentinel集群的分布式设计，至少需要3个Sentinel实例组成集群，确保即使单个Sentinel故障，系统仍能正常工作。

哨兵如何监控故障转移

哨兵通过心跳检测监控Redis节点，主观下线（Subjectively Down, SDOWN）是单个哨兵认为节点不可用，主观判断后通过Sentinel间的消息总线通知其他哨兵。

当足够数量的哨兵（quorum参数定义）确认故障后，触发客观下线（Objectively Down, ODOWN），选举Leader哨兵执行故障转移：命令从节点执行slaveof no one提升为主，并通知其他从节点同步新主。

故障转移过程包括发现故障、选举领导者、选择新主、更新配置，整个过程自动化完成，通常在几秒到几十秒内切换，避免服务中断。

Redis哨兵配置常见问题

配置sentinel.conf时，sentinel monitor mymaster 127.0.0.1 6379 2，其中quorum设为2表示至少2个哨兵同意故障；常见问题是quorum太小导致脑裂，建议至少3个哨兵 quorum=2。

另一个问题是down-after-milliseconds参数，默认30秒，太长会延迟故障检测，太短易误判，实际环境建议5000-10000ms，根据网络延迟调整。

启动多个哨兵需指定不同端口如26379、26380，并确保它们能互相发现，配置sentinel announce-ip和announce-port避免NAT环境问题。

FAQ:
Q: 哨兵如何避免脑裂？
A: 通过quorum参数要求多数哨兵同意客观下线，并使用Leader选举机制确保只有一个哨兵执行转移。
Q: 配置哨兵集群需要几个实例？
A: 至少3个奇数个，以保证多数派投票有效。
Q: 主节点故障恢复后会怎样？
A: 恢复节点会自动变为新主节点的从节点，继续同步数据。
Q: sentinel monitor命令的作用？
A: 定义监控的主节点IP、端口和quorum值，是哨兵配置文件的核心。