1. 架构原理与组成
1.1 组件与职责
在Redis哨兵架构中，核心由若干独立的哨兵实例、一个或多个主节点以及若干个从节点组成。哨兵实例并非数据存储的主体，而是对主从复制拓扑的监控与管理单元，负责实现高可用的故障转移能力。
每个哨兵都具备对主节点和从节点状态的健康检查、状态记录与通知能力，通过PING、心跳等机制获取集群的最新状态。多实例冗余让单点故障不会导致整个哨兵集群失效，从而提升系统的可用性。
1.2 心跳与健康检查机制
哨兵通过健康检查来判断节点是否可达，含有主节点在线检测、从节点可投票性以及阈值设置等要素。若大多数哨兵判定主节点不可用，系统进入故障转移候选阶段。
健康检查的关键参数包括down-after-milliseconds、quorum以及failover-timeout等，它们共同决定了从检测到触发故障转移的时间及容错条目。正确的参数能有效避免误判与过早切换。
2. 故障转移全过程解析
2.1 监控与触发条件
在监控阶段，哨兵持续轮询主节点及从节点的健康状况，一旦主节点被判定为下线，并且达到quorum数量的哨兵同意，哨兵集群进入故障转移候选。
触发条件通常包括：主节点不可达超过 down-after-milliseconds的时间阈值，且有足够数量的哨兵同意实现锁定与选举。此时系统将启动新主的选举流程，并准备把其他从节点指向新主。
# sentinel.conf 示例配置片段
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
2.2 主从切换执行流程
当故障转移进入正式阶段，多数哨兵将选出一个从节点晋升为新的主节点，新主将承担对外的写入与对从节点的复制职责。与此同时，其他从节点将重新配置为从新主节点同步，确保数据复制的一致性。
升级完成后，哨兵会通过内部通信更新客户端的目标主机信息，确保应用程序的连接走向新主。此过程通常对外透明，但对内部复制连贯性与延迟有直接影响。
# 触发手动故障转移（仅用于演示）
redis-cli -p 26379 SENTINEL failover mymaster
# 查看当前主从地址
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
2.3 客户端连接更新与数据一致性
在故障转移完成后，客户端需要通过哨兵发现当前Master来重新建立连接，避免继续向旧主写入。通常做法是让客户端通过SENTINEL接口获取当前 Master 的地址，或采用客户端库的自动重试机制。
常用查询命令包括：SENTINEL get-master-addr-by-name，它返回当前Master的IP与端口，客户端据此重新连接。若叠加从节点重新配置，客户端也需要关注从节点状态与复制偏移，确保数据一致性。
# 获取当前 master 地址（IP, Port）
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# 查看哨兵当前对 mymaster 的监控状态
redis-cli -p 26379 SENTINEL masters
3. 实战要点与运维要点
3.1 配置与部署要点
在生产环境中，需要至少3个哨兵实例以形成法定多数，推荐部署在不同的机器或可用区以降低单点故障风险。为避免网络分区导致的误触发，应为quorum设置合理的数量与结构，通常是2或3的倍数。
另外，主从复制拓扑要稳定，每个哨兵都应指向同一主，并确保down-after-milliseconds等参数一致；同时对parallel-syncs、failover-timeout等进行规范化配置，防止并发故障转移导致的冲突。
3.2 监控与故障排查
日常运维应对哨兵日志与状态进行持续监控，使用 SENTINEL masters、SENTINEL sentinels 命令查看主从关系与哨兵健康状况，及时发现潜在的单点或网络问题。
常见排查手段包括：检查网络连通性、确认 Redis 版本一致性、核验 sentinel.conf 的参数是否在所有节点一致、以及对故障转移超时与并行同步数进行调参。
# 查看当前哨兵关注的 Masters 列表
redis-cli -p 26379 SENTINEL masters
# 查看某个 Master 的从节点及状态
redis-cli -p 26379 SENTINEL slaves mymaster
# 检查哨兵实例列表与健康情况
redis-cli -p 26379 SENTINEL sentinels mymaster
3.3 常见坑点与应对
常见问题包括网络分区引发的split-brain场景、错误的 quorum 导致的频繁故障转移、以及客户端未及时从哨兵获取新主而造成写入错向。为降低风险，应在不同的可用区布置哨兵，并在应用层实现对哨兵与主从变更的容错处理。
另外，监控阈值与时间参数的合理化至关重要，过低的 down-after-milliseconds 容易导致误判，过高则延迟故障转移；应结合业务峰谷、网络延迟、以及 Redis 数据量进行逐步调参。
