Redis如何实现故障自动恢复？浅析哨兵的工作原理

Redis通过哨兵（Sentinel）机制实现故障自动恢复，其核心原理是通过多哨兵节点协作监控主从集群状态，并在主节点故障时自动完成主从切换。以下是具体实现原理的分步解析：

Redis的高可用依赖多副本部署和自动故障恢复，常见部署模式如下：

• 单节点部署：无冗余，故障时数据丢失，业务中断。
• Master-Slave部署：读写分离提升性能，但需手动切换主节点，业务中断时间取决于操作延迟。
• Master-Slave+哨兵部署：哨兵自动监控主节点状态，故障时自动提升从节点为主节点，最大限度减少业务中断时间。

关键点：主从复制（Master-Slave Replication）保证数据多副本，哨兵实现自动化故障转移。

哨兵是Redis的高可用解决方案，主要功能包括：

• 监控：持续检查主从节点健康状态。
• 通知：通过发布订阅（Pub/Sub）机制传播节点状态变化。
• 自动故障转移：主节点故障时，自动选举新的主节点并完成切换。

部署建议：

• 哨兵节点数量为奇数（如3、5个），避免网络分区导致决策错误。
• 哨兵节点分布在不同物理机，提升检测准确性。

哨兵的工作流程分为以下阶段：

• 拓扑信息收集：哨兵每10秒向主节点发送INFO命令，获取主从拓扑关系（从节点地址、端口等），并记录所有节点信息。
• 哨兵间通信：哨兵通过主节点的__sentinel__:hello频道交换自身状态和主节点信息，实现以下目的：

  发现其他哨兵节点，建立通信基础。

  共享主节点状态，为故障判断提供依据。

• 主观下线（SDown）：哨兵每1秒向主、从节点及其他哨兵发送PING命令，若节点未在down-after-milliseconds时间内响应，则标记为主观下线。
• 客观下线（ODown）：当超过quorum（配置的哨兵数量阈值，如2/3）的哨兵认为主节点主观下线时，标记为客观下线，触发故障转移流程。

设计原因：避免因网络分区误判主节点故障。

• 共识算法：哨兵通过类似Raft的算法选举领导者，流程如下：

  每个哨兵设置随机超时时间，超时后发起选举请求。

  其他哨兵仅对首个收到的请求回复确认。

  首个获得多数选票的哨兵成为领导者，负责故障转移操作。

  若选举失败，重新进入超时和选举流程。

作用：确保故障转移由单一领导者协调，避免冲突。

领导者从客观下线的主节点的从节点中，按以下优先级选择新主节点：

1. Slave Priority：配置中优先级最高的从节点（数值越小优先级越高）。
2. 数据完整性：复制偏移量（master_repl_offset）最大的从节点（数据最完整）。
3. Run ID最小：若前两项相同，选择Run ID最小的从节点。

1. 提升新主节点：领导者向选中的从节点发送SLAVEOF NO ONE命令，使其成为新主节点。
2. 重定向其他从节点：向原主节点的其他从节点发送SLAVEOF $newmaster命令，使其成为新主节点的从节点。
3. 处理原主节点：将原主节点降级为从节点，待其恢复后自动同步新主节点数据。

• 发布订阅通知：哨兵通过__sentinel__:hello频道发布新主节点信息，客户端订阅该频道获取变更。
• 主动查询：客户端可直接向哨兵发送SENTINEL get-master-addr-by-name命令查询当前主节点地址。
• 钩子机制：在哨兵配置中定义脚本，在故障转移完成后触发通知逻辑（如发送邮件、调用API等）。

Redis哨兵通过以下机制实现高可用：

1. 多哨兵协作：避免单点误判，提升故障检测准确性。
2. 自动化流程：从故障检测到主从切换全程自动化，减少人工干预。
3. 优先级策略：确保新主节点数据完整且稳定。
4. 客户端适配：支持多种方式感知主节点变更，兼容不同业务场景。

适用场景：需要高可用、低延迟的缓存或数据存储场景（如电商、金融系统）。通过合理配置哨兵节点数量和参数，可满足不同级别的可用性需求（如99.9%、99.99% SLA）。