1. 哨兵模式概述
Redis 哨兵（Sentinel）是 Redis 官方提供的高可用（HA）解决方案。在微服务与后端安全合规场景中，哨兵模式确保 Redis 主节点发生故障时，系统能自动完成故障转移，从而避免因缓存中断导致的业务断言失败或安全审计中断。本节从架构原理、核心组件与故障转移流程三个维度展开。
1.1 架构原理
哨兵模式基于分布式监控 + 选举 + 故障转移机制运行。一个典型的哨兵集群包含多个哨兵进程（通常为奇数个，如 3 或 5），它们彼此通信，共同监控一组 Redis 主从节点。当主节点不可达时，哨兵通过 Raft 类共识算法 选举出 Leader，由 Leader 执行故障转移，将从节点提升为新的主节点，并更新客户端配置。
架构要点：
- 哨兵自身也是分布式进程，避免单点故障。
- 哨兵与哨兵之间通过
__sentinel__:hello频道交换信息。 - 客户端通过哨兵获取当前主节点地址，实现透明切换。
1.2 核心组件
哨兵模式由三类角色组成，每类角色承担不同的职责。下表从角色、数量、职责、安全合规关注点四个维度进行对比：
| 组件 | 推荐数量 | 核心职责 | 安全合规关注点 |
|---|---|---|---|
| 主节点 (Master) | 1 | 处理读写请求；数据持久化 | 必须开启密码认证；审计日志记录写操作 |
| 从节点 (Replica) | 1~N | 复制主节点数据；提供读能力；故障时被提升 | 只读权限；禁止执行 FLUSHALL 等危险命令 |
| 哨兵 (Sentinel) | ≥3（奇数） | 监控主从状态；自动故障转移；通知客户端 | 独立配置认证；限制哨兵命令集；日志审计 |
合规提示：在金融、医疗等监管严格场景中，哨兵进程应部署在独立的安全域，并通过 TLS 加密哨兵间通信，防止中间人攻击导致错误的主节点切换。
1.3 故障转移流程
故障转移是哨兵模式的核心价值。整个流程分为主观下线 → 客观下线 → 选举 Leader → 故障转移 → 通知客户端五个阶段。以下为详细步骤：
- 主观下线 (SDOWN)：单个哨兵发现主节点在
down-after-milliseconds时间内未响应 PING，标记为主观下线。 - 客观下线 (ODOWN)：该哨兵通过
sentinel is-master-down-by-addr命令向其他哨兵询问，当超过quorum数量的哨兵确认主节点不可达时，标记为客观下线。 - 选举 Leader：哨兵集群使用 Raft 类算法选举一个 Leader 负责执行故障转移。选举基于
runid和配置纪元（epoch）。 - 故障转移执行：Leader 从从节点列表中选出一个最优从节点（优先级高、复制偏移量大、runid 小），执行
SLAVEOF NO ONE将其提升为新主节点，并让其他从节点复制新主节点。 - 通知客户端：哨兵通过 Pub/Sub 频道
+switch-master发布新主节点信息，客户端订阅后更新连接。
1.4 故障转移中的安全合规要点
在后端安全合规场景中，故障转移不仅仅是技术切换，还涉及身份认证、命令审计、数据一致性等合规要求。以下为关键实践：
| 合规维度 | 要求 | 哨兵模式实现方式 |
|---|---|---|
| 身份认证 | 所有节点必须密码认证 | 主从配置 requirepass；哨兵配置 sentinel auth-pass |
| 命令审计 | 记录危险命令执行日志 | 启用 rename-command FLUSHALL ""；审计日志输出到独立文件 |
| 数据一致性 | 故障转移后不丢失已确认写入 | 使用 min-replicas-to-write + min-replicas-max-lag 保证同步 |
| 通信加密 | 哨兵间、哨兵与节点间 TLS | 配置 tls-port、tls-cert-file、tls-key-file |
常见错误码断言场景：当哨兵故障转移后，客户端仍使用旧主节点 IP 连接时，会收到
READONLY You can't write against a read only replica 错误。后端应通过哨兵 API 动态获取主节点地址，并在错误码断言中捕获此异常，触发重试逻辑。