Redis 哨兵模式详解：自动故障转移配置实战

一、引言

在分布式系统中，高可用性是保障业务连续性的关键指标。Redis作为高性能的内存数据库，其哨兵模式（Sentinel）通过自动化监控与故障转移机制，为Redis主从架构提供了可靠的高可用解决方案。本文ZHANID工具网将深入解析哨兵模式的核心原理、配置方法及实战操作，帮助开发者快速掌握这一关键技术。

二、哨兵模式的核心原理

2.1 架构组成

哨兵模式由三部分构成：

• 主节点（Master）：承担写操作的核心节点，通过异步复制将数据同步至从节点。

• 从节点（Slave）：提供读操作支持，数据与主节点保持最终一致性。

• 哨兵节点（Sentinel）：独立运行的监控进程，负责检测主从节点状态并执行故障转移。

典型部署架构为 1主+N从+M哨兵（如1主2从+3哨兵）。哨兵节点需独立部署于不同物理机，避免单点故障。

2.2 核心机制

2.2.1 心跳检测与故障判定

• 主观下线（SDOWN）：单个哨兵在down-after-milliseconds（默认30秒）内未收到节点响应，标记为主观下线。

• 客观下线（ODOWN）：当超过quorum（法定人数，如3哨兵中2个确认）的哨兵判定主节点主观下线后，触发客观下线状态。

2.2.2 领导者选举与故障转移

• Raft算法选举：哨兵集群通过投票选举领导者，负责协调故障转移流程。

• 新主节点选举规则：

1. 优先级筛选：选择replica-priority值最低的从节点（默认100，0表示不参与选举）。

2. 数据完整性：优先选择复制偏移量（master_repl_offset）最大的从节点。

3. 运行ID最小：若前两项相同，选择运行ID（runid）最小的节点。

2.2.3 配置更新与通知

• 从节点重定向：领导者哨兵向新主节点发送SLAVEOF NO ONE命令，并通知其他从节点切换复制源。

• 客户端通知：通过发布/订阅机制（+switch-master频道）通知客户端新主节点地址。

三、哨兵模式配置实战

3.1 环境准备

• 硬件要求：3台独立服务器（避免伪分布式部署），每台运行Redis 6.0+版本。

• 网络配置：确保哨兵与主从节点间网络延迟