一、Redis 哨兵模式的核心作用
- 故障自动检测：监控主节点和从节点的健康状态。
- 自动故障转移：主节点不可用时，选举新的主节点并更新配置。
- 客户端透明切换：客户端通过哨兵节点获取最新的主节点地址。
- 通知与告警：支持通过脚本或 API 通知管理员故障事件。
二、Redis 哨兵模式的架构与机器要求
最小化部署架构
-
机器数量 ：至少 3 台（避免单点故障）。
-
角色分配：
- 1 台主节点（Master） ：处理写请求。
- 2 台从节点（Slave） ：复制主节点数据，处理读请求。
- 3 台哨兵节点（Sentinel） ：通常与 Redis 节点部署在同一台机器，减少资源开销。
三、Redis 哨兵模式配置步骤
1. 主从节点配置
主节点（Master）配置（redis-master.conf）：
bash
port 6379
daemonize yes
logfile "/var/log/redis/redis-master.log"从节点（Slave）配置（redis-slave1.conf）：
bash
port 6380
daemonize yes
logfile "/var/log/redis/redis-slave1.log"
replicaof 192.168.1.100 6379 # 指向主节点IP和端口2. 哨兵节点配置
每个哨兵节点需独立配置（以 sentinel1.conf 为例）：
bash
port 26379
daemonize yes
logfile "/var/log/redis/sentinel1.log"
sentinel monitor mymaster 192.168.1.100 6379 2 # 监控主节点，2表示需2个哨兵同意故障转移
sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判定为宕机
sentinel failover-timeout mymaster 10000 # 故障转移超时时间
sentinel parallel-syncs mymaster 1 # 故障转移时允许同步的从节点数3. 启动命令
bash
# 启动主从节点
redis-server /path/to/redis-master.conf
redis-server /path/to/redis-slave1.conf
# 启动哨兵节点
redis-sentinel /path/to/sentinel1.conf四、实际案例：3 台机器的哨兵模式部署
1. 机器与角色分配
| 机器IP | Redis角色 | 哨兵节点端口 |
|---|---|---|
| 192.168.1.100 | Master (6379) | Sentinel (26379) |
| 192.168.1.101 | Slave1 (6380) | Sentinel (26380) |
| 192.168.1.102 | Slave2 (6381) | Sentinel (26381) |
2. 验证哨兵状态
bash
redis-cli -h 192.168.1.100 -p 26379 info sentinel输出示例：
plaintext
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.1.100:6379,slaves=2,sentinels=3五、哨兵模式的工作流程
1. 故障检测流程
sequenceDiagram
participant Sentinel1
participant Master
participant Sentinel2
participant Sentinel3
Sentinel1->>Master: PING (每1秒)
Master-->>Sentinel1: PONG
Note over Master: 主节点宕机
Sentinel1->>Master: PING (超时5秒未响应)
Sentinel1->>Sentinel2: 发起主观下线(SDOWN)
Sentinel1->>Sentinel3: 发起主观下线(SDOWN)
Sentinel2->>Sentinel1: 确认客观下线(ODOWN)
Sentinel3->>Sentinel1: 确认客观下线(ODOWN)
2. 故障转移流程
- 选举领导者哨兵：通过 Raft 算法选举一个领导者哨兵。
- 选择新主节点：根据优先级、复制偏移量等条件选择从节点。
- 提升新主节点 ：执行
REPLICAOF NO ONE命令。 - 切换从节点：更新其他从节点指向新主节点。
- 通知客户端：通过发布订阅机制通知客户端新主节点地址。
六、哨兵模式的注意事项
- 网络分区问题：哨兵可能因网络分区误判主节点宕机，需合理配置超时时间。
- 最少哨兵节点数：至少 3 个哨兵节点以避免"脑裂"问题。
- 客户端兼容性：客户端需支持哨兵协议（如 Jedis、Lettuce）。
- 监控与告警 ：通过
sentinel.log和 Prometheus + Grafana 监控哨兵状态。
七、总结
哨兵模式的适用场景
- 需要高可用性的 Redis 服务。
- 中小规模集群（大规模集群推荐 Redis Cluster）。
- 对自动化运维有较高需求的场景。
哨兵模式的优缺点
| 优点 | 缺点 |
|---|---|
| 自动化故障转移 | 配置复杂度较高 |
| 支持读写分离（从节点读） | 数据一致性可能短暂丢失 |
| 客户端透明切换 | 网络分区可能导致误判 |