1. 生产环境下的 Redis Sentinel 高可用架构
1.1 架构目标与工作原理
在高并发生产环境中，Redis Sentinel 提供了监控、自动故障转移与通知等能力，核心目标是确保主从复制拓扑在节点发生故障时仍具备可用性与一致性。通过 多节点监控与投票仲裁，能够在主节点出现不可用时快速触发切换。预设的投票门槛与心跳检测决定故障转移是否成立，从而降低业务中断风险。
工作原理简述：哨兵组通过持续的健康检查来判断主节点是否可达，一旦检测到不可用，会按照配置的投票规则发起故障转移。新主节点的选举会基于多数派意见，并且在完成切换后向从节点下发重新订阅信息，确保数据在副本之间保持一致性。告警与通知机制也会将故障信息推送给运维端，便于快速处置。
在生产环境中，合理的哨兵规模、网络分离与时钟同步对稳定性至关重要，这是避免脑裂和误判的关键点。至少三台哨兵实例的部署通常被推荐，以实现可用性更高的多数派参与。
1.2 节点角色与参与者
该架构核心的角色包括 Master（主节点）、Slave（从节点） 与 Sentinel（哨兵）。Master 提供写入与强一致性读取，Slave 作为只读/备份节点，用于提升读取吞吐与数据冗余；Sentinel 负责监控、通知与自动故障转移，确保拓扑在异常时仍能快速自愈。
在故障转移场景中，哨兵通过 quorum（投票阈值）进行仲裁，选出新的 Master，并要求从节点重新对接收到新的主机地址。网络分区与时钟漂移可能影响投票结果，因此需要额外的 时钟对齐和网络分区策略来提升稳健性。
2. 面向生产环境的部署要点
2.1 节点拓扑与分布式部署策略
在生产场景中，推荐的实践是将 Master、Slave 与 Sentinel 分布在不同的物理或云段，以提升容错能力。至少三台 Sentinel 应部署在不同网络分区，确保在某一路由不可用时仍能完成多数派投票。Master 与 Slave 的分布应避免单点暴露，且应考虑跨区域部署以应对区域性故障。
为了提升稳定性，应该采用 持久化策略（AOF 与/或 RDB），以及 网络带宽和延迟优化，以减少复制延迟对故障转移时序的影响。监控指标与告警阈值应与业务 SLA 对齐，避免误报造成生产波动。
2.2 Sentinel 集群配置与启动方式
在部署时，需要为每个哨兵节点配置独立的哨兵配置文件（sentinel.conf），并确保 监控的主节点信息、端口与投票门槛明确。主节点信息与从节点信息的动态更新，在故障转移后要能够及时生效。
常见的启动方式包括单机启动多实例的哨兵进程，或通过编排工具来实现并行启动与健康自愈。下面给出一组示例片段，帮助快速落地生产环境的配置：
# redis.conf（master/slave 公共配置片段）
appendonly yes
appendfilename "appendonly.aof"
requirepass yourpass
masterauth yourpass
# sentinel.conf（哨兵监控配置示例）
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel auth-pass mymaster yourpass
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
# docker-compose.yaml（简化编排示例，实际环境可扩展）
version: '3.8'
services:redis-master:image: redis:7-alpinecontainer_name: redis-mastercommand: redis-server /etc/redis/redis.confvolumes:- ./redis-master.conf:/etc/redis/redis.confredis-slave:image: redis:7-alpinecontainer_name: redis-slavecommand: redis-server /etc/redis/redis.confsentinel:image: redis/redis-sentinel:6container_name: redis-sentinelcommand: redis-sentinel /etc/sentinel.confdepends_on:- redis-master- redis-slave
此外，部署脚本与自检流程应覆盖至少三步走：启动、健康检查与故障转移回滚的测试，确保在正式流量进入前达到可观测的稳定性。
高可用配置的关键点包括：三冗余的 Sentinel、跨机房网络设计、清晰的故障转移策略以及一致性与可观测性的平衡。
在生产环境中，对 Master 的连接字符串应通过 Sentinel 提供的 API 动态获取，避免硬编码带来的升级成本与不可用风险。
2.3 数据持久化与一致性策略
为降低数据丢失风险，AOF 与 RDB 双重持久化是常见的组合。应设定合理的 快照频率与增量写入策略，同时监控 复制延迟，确保从节点在故障转移后尽可能处于最新状态。
从客户端角度，通过 Sentinel 获取当前 Master 的地址，以确保在切换后仍能正确路由请求。关闭写入保护策略与持久化配置冲突，确保故障转移期间数据的一致性与可用性之间达到平衡。
3. 监控、告警与可观测性
3.1 指标要点
监控维度应覆盖 哨兵健康状态、主从复制参数、以及网络层的健康状况。典型指标包括 sentinel_masters、master_last_io_seconds、slave_repl_offset，以及 主节点宕机检测、投票通过率与切换时间等。
还应关注 复制偏差、RDB/AOF 持久化进度、磁盘 I/O 与 CPU 使用率，以便在异常出现前进行容量与性能调整。
3.2 告警策略与仪表盘
推荐结合 Prometheus + Redis Exporter 或内置指标进行集中化告警。核心告警策略包括 MASTER DOWN、SLAVE DOWN、投票失败、故障转移超时等情形，以及 重复触发的告警抑制策略，以避免告警疲劳。
典型的告警示例包括：当 master_down_since_seconds> 300 时触发高优告警；当 replication_delay 超过阈值则触发性能告警；以及 sentinel_scrape_failures 告警表示监控端口可达性问题。
# Prometheus 规则示例（简化）
alert: RedisMasterDown
expr: redis_up{job="redis"} == 0
for: 5m
labels:severity: critical
annotations:summary: "Redis master is down"description: "Master instance {{ $labels.instance }} has been down for more than 5 minutes."
4. 故障恢复与故障转移流程
4.1 自动故障转移流程
当 Master 检测失败且达到 quorum（投票阈值）后，哨兵会触发故障转移，选出新的 Master，并将从节点重新指向新主。此过程通常包含以下阶段：主节点不可用检测 → 投票仲裁 → 选举新 Master → 从节点重新配置 → 客户端连接信息更新。
在故障转移完成后，从节点会自动对新主进行重连与数据同步，并且 监控系统会更新主从关系状态，以便尽快将业务流量路由到新的 Master。
为确保安全与可控性，手动干预应仅在复杂故障场景下执行，并且需要对照 SENTINEL get-master-addr-by-name、master replicas 状态与投票结果进行回放验证。
# 查看当前 Sentinel 管控的主从信息
redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster# 强制触发一次故障转移（仅在测试环境使用）
redis-cli -p 26379 SENTINEL failover mymaster
4.2 手动干预与风险控制
在生产环境中，自动故障转移优先级较高，但需要可控的回滚策略。在允许的情况下，运维应具备对 生效的故障转移结果进行人工复核的能力，并确保对外部客户端的影响最小化。回滚计划、数据一致性检查与业务中断时间窗应提前演练。
此外，网络分区情况下的脑裂风险控制需要通过 时钟一致性、投票门槛与分组部署策略来降低。对关键路径上的依赖客户端，建议实现 动态发现 Master 的机制，以减少因故障转移引起的连接中断。
5. 部署与运维的实战要点
5.1 版本升级与向后兼容性
在升级 Redis 与 Sentinel 版本时，先在测试环境验证，确保新版本对现有主从结构的兼容性。版本回滚路径要清晰，确保在异常时能够快速恢复到稳定版本。配置文件格式变更也需同步，避免因解析失败导致服务不可用。
5.2 安全性与访问控制
应启用强认证机制，为主从通信与哨兵之间的交互设置强口令，并且将 哨兵端口与 Redis 端口分离，以降低暴露面。最小化暴露面、定期轮换密钥与审计日志，是提升整体安全性的核心。
5.3 备份与灾难恢复演练
应定期对 RDB/AOF 文件以及哨兵配置进行备份，并执行 灾难恢复演练，以验证在跨机房、跨区域的故障场景下仍能按预期工作。演练记录与改进措施应纳入日常运维流程。
