2. Redis哨兵模式基础：哨兵架构、故障转移、高可用原理

在微服务架构中，Redis 作为缓存层承担着极高的并发压力。一旦 Redis 主节点宕机，整个微服务链路可能瞬间雪崩。哨兵模式（Sentinel）正是为解决这一问题而设计的分布式高可用解决方案。本章将深入剖析哨兵的核心架构、故障转移机制以及高可用原理，为后续连接池调优打下坚实基础。

2.1 哨兵架构：三节点最小高可用单元

哨兵模式并非单点，而是一个由多个哨兵进程组成的分布式监控系统。一个标准的哨兵架构至少包含以下角色：

下图展示了一个典型的 3 哨兵 + 1 主 2 从的高可用架构：

2.2 哨兵的核心功能：监控、通知、配置、故障转移

哨兵节点在启动后，会持续执行以下四项核心任务：

1. 监控（Monitoring）：哨兵每隔 1 秒（默认 sentinel monitor 间隔）向所有已知的主节点、从节点和其他哨兵发送 PING 命令，检查其可达性。
2. 通知（Notification）：当被监控的 Redis 实例发生异常时，哨兵通过发布/订阅模式向客户端或其他哨兵发送告警消息。
3. 配置提供（Configuration Provider）：客户端连接哨兵，询问当前主节点的地址。哨兵返回最新的主节点信息，实现客户端“服务发现”。
4. 故障转移（Failover）：当主节点被判定为客观下线后，哨兵集群自动选举一个从节点升级为新的主节点，并更新其他从节点的复制目标。

2.3 故障转移流程：从主观下线到新主上任

故障转移是哨兵模式最核心的机制，分为以下 5 个关键步骤：

下图展示了故障转移的完整时序流程：

2.4 高可用原理：Raft 协议与配置纪元

哨兵模式的高可用性建立在两个核心机制之上：

• Raft 领导者选举：当需要执行故障转移时，哨兵集群通过 Raft 协议选举一个领导者。每个哨兵节点拥有投票权，获得超过半数投票的哨兵成为领导者。这保证了在分布式环境下，只有一个哨兵负责执行转移，避免冲突。
• 配置纪元（Configuration Epoch）：每次故障转移都会产生一个新的纪元编号（epoch）。哨兵通过纪元来区分新旧配置，防止网络分区恢复后旧主节点重新上线导致的数据混乱。客户端和从节点只信任最新纪元的配置。

2.5 哨兵模式与微服务的适配要点

在微服务架构中，哨兵模式不仅仅是“高可用”，更是“服务发现”的关键组件。以下是几个适配要点：

在微服务中，推荐使用支持哨兵模式的 Redis 客户端（如 Jedis、Lettuce、Redisson），它们内置了哨兵感知和连接池自动刷新能力，能够大幅降低故障转移对业务的影响。