Redis 哨兵模式详解：实现高可用的自动故障转移方案

Redis 哨兵模式详解：实现高可用的自动故障转移方案

在 Redis 的主从复制架构中，虽然解决了数据备份和读写分离的问题，但当主节点发生故障时，需要人工介入进行主从切换，这在大规模应用中显然无法满足高可用性需求。为此，Redis 从 2.8 版本开始引入了 Sentinel（哨兵）机制，实现了主节点故障的自动检测和故障转移功能。本文将详细介绍 Redis 哨兵模式的工作原理、配置方法及实践要点。

一、哨兵模式核心概念

1.1 哨兵的作用

哨兵（Sentinel）是 Redis 提供的一种高可用解决方案，其核心功能包括：

• 持续监控主从节点的运行状态
• 当主节点故障时自动进行故障转移
• 通知客户端新的主节点地址
• 自动更新主从配置信息

1.2 主观宕机与客观宕机

哨兵机制中存在两种节点状态判断：

• 主观宕机（SDOWN）：单个哨兵进程判断某个节点不可用（如指定时间内未收到响应）
• 客观宕机（ODOWN）：多数哨兵进程（通常超过半数）都判断主节点为 SDOWN 状态，经过协商后确认的宕机状态

只有当主节点被判定为客观宕机时，才会触发故障转移流程。

1.3 故障转移的选举策略

当主节点被判定为客观宕机后，哨兵会从剩余的从节点中选举新的主节点，选举遵循以下优先级：

1. 优先级优先：通过replica-priority配置（默认 100，值越小优先级越高）
2. 数据完整性优先：选择偏移量最大的从节点（即同步主节点数据最完整的节点）
3. 运行 ID 优先：在以上条件相同时，选择 runid（实例启动时生成的 40 位唯一标识）最小的节点

1.4 哨兵集群规模

为保证哨兵机制的可靠性，建议哨兵节点数量：

• 至少 3 个节点
• 最好为奇数（避免投票时出现平票）

二、哨兵模式配置实践

2.1 环境准备

本文将配置一主两从三哨兵的架构，节点信息如下：

• 主节点：192.168.2.20:6379
• 从节点 1：192.168.2.21:6379
• 从节点 2：192.168.2.22:6379
• 三个哨兵分别部署在以上三台服务器，端口均为 26379

2.2 配置主从复制

主节点配置（192.168.2.20）：

# 安装Redis
[root@redis-master ~]# yum install redis -y# 编辑配置文件
[root@redis-master ~]# vim /etc/redis/redis.conf
# 修改以下配置
bind 0.0.0.0
protected-mode no
daemonize no  # 重启服务
[root@redis-master ~]# systemctl restart redis

验证主节点状态：

[root@redis-master ~]# redis-cli
127.0.0.1:6379> info replication # 应显示role:master及连接的从节点信息
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.2.22,port=6379,state=online,offset=56,lag=1
slave1:ip=192.168.2.21,port=6379,state=online,offset=56,lag=1
master_failover_state:no-failover
master_replid:f9a6754f8b46599474ad5b3f84945af03513fbd9
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:70
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:70

从节点配置（192.168.2.21 和 192.168.2.22）：

# 安装Redis（同上）# 编辑配置文件
[root@redis-slave1 ~]# vim /etc/redis/redis.conf
# 修改基础配置
bind 0.0.0.0
protected-mode no
daemonize no  
# 添加主节点信息
replicaof 192.168.2.20 6379# 重启服务
[root@redis-slave1 ~]# systemctl restart redis

验证从节点状态：

[root@redis-slave1 ~]# redis-cli
127.0.0.1:6379> info replication # 应显示role:slave及对应的主节点信息
# Replication
role:slave
master_host:192.168.2.20
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:70
slave_repl_offset:70
slave_priority:100
slave_read_only:1

slave2同slave1

2.3 配置哨兵集群

在主节点（192.168.2.20）上配置哨兵：

vim /etc/redis/sentinel.conf
# 添加以下核心配置
port 26379                  # 哨兵监听端口
daemonize no                # 后台运行
pidfile /var/run/redis-sentinel.pid
logfile /var/log/redis/sentinel.log
# 监控主节点：名称为mymaster，地址192.168.2.20:6379，需要2个哨兵确认宕机
sentinel monitor mymaster 192.168.2.20 6379 2
sentinel down-after-milliseconds mymaster 30000  # 30秒未响应视为宕机
sentinel parallel-syncs mymaster 1                # 故障转移后同时同步的从节点数
sentinel failover-timeout mymaster 180000         # 故障转移超时时间（3分钟）

将配置文件复制到其他两个哨兵节点：

scp /etc/redis/sentinel.conf root@192.168.2.21:/etc/redis/
scp /etc/redis/sentinel.conf root@192.168.2.22:/etc/redis/

启动所有哨兵（分别在三台服务器执行）：

# 方式一：后台启动
redis-sentinel /etc/redis/sentinel.conf &# 方式二：通过系统服务启动
systemctl start redis-sentinel#两者选其一，不能同时用

⚠️ 注意：哨兵启动后会自动修改 sentinel.conf 文件，如需重新配置，建议删除原文件后重新编辑。

三、故障转移测试

3.1 模拟主节点故障

在主节点（192.168.2.20）执行：

[root@redis-master ~]# redis-cli
127.0.0.1:6379> SHUTDOWN  # 关闭主节点
# 或使用systemctl stop redis

3.2 验证故障转移结果

在从节点 2（192.168.2.22）查看状态：

[root@redis-slave2 ~]# redis-cli
127.0.0.1:6379> info replication # 应显示role:master，并有一个从节点（192.168.2.21）
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.2.21,port=6379,state=online,offset=83956,lag=0
master_failover_state:no-failover
master_replid:d02e650fcd4fcb390363b7c1ea0701ed236600a6
master_replid2:f9a6754f8b46599474ad5b3f84945af03513fbd9
master_repl_offset:84099
second_repl_offset:73296
repl_backlog_active:1

在从节点 1（192.168.2.21）查看状态：

[root@redis-slave1 ~]# redis-cli
127.0.0.1:6379> info replication # 应显示role:slave，主节点变为192.168.2.22
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.2.22
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:92749
slave_repl_offset:92749
slave_priority:100
slave_read_only:1

3.3 原主节点恢复后的状态

重启原主节点（192.168.2.20）：

[root@redis-master ~]# systemctl start redis
[root@redis-master ~]# redis-cli
127.0.0.1:6379> info replication # 原主节点将变为从节点，主节点为192.168.2.22
# Replication
role:slave
master_host:192.168.2.22
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:138886
slave_repl_offset:138886
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:7854d09b93aee75454ee12c3bebb5c90eb98c871
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:138886
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:136209
repl_backlog_histlen:2678

四、生产环境注意事项

4.1 数据一致性问题

由于主从同步存在延迟，在高负载场景下可能导致数据不一致。解决办法：

# 配置主节点至少需要2个从节点正常同步才允许写入
[root@redis-slave2 ~]# redis-cli
127.0.0.1:6379> config get min-slaves-to-write
1) "min-slaves-to-write"
2) "0"
127.0.0.1:6379> config set min-slaves-to-write 2
OK
127.0.0.1:6379> config get min-slaves-to-write
1) "min-slaves-to-write"
2) "2"
# 永久生效需写入redis.conf

4.2 网络分区问题

当主节点与从节点 / 哨兵发生网络分区时，可能出现：

• 哨兵误认为主节点宕机并选举新主节点
• 原主节点恢复后会自动变为从节点
• 原主节点在网络分区期间的写入数据会被清空

4.3 哨兵集群维护

• 定期备份哨兵配置文件（哨兵运行中会自动更新）
• 监控哨兵日志，及时发现异常
• 避免哨兵与 Redis 节点部署在同一物理机，防止单点故障

五、总结

Redis 哨兵模式通过自动故障转移解决了主从架构的高可用问题，但其仍存在单个主节点的性能瓶颈。在实际应用中，应根据业务规模选择合适的架构：

• 中小规模应用：哨兵模式足以满足需求
• 大规模应用：建议考虑 Redis Cluster 集群方案

通过合理配置哨兵参数和主从策略，可以有效提升 Redis 服务的可用性和数据安全性，为业务系统提供稳定可靠的缓存支持