Redis 哨兵（Sentinel）模式部署教程（基于一主二从架构）

本文承接上一篇《Redis 单机一主二从主从复制完整搭建》，在已有的 6379(主)、6380(从)、6381(从) 架构基础上，手把手部署三哨兵节点，实现主节点故障自动转移，提升服务可用性。

---

一、架构规划与前置条件

1.1 架构说明

• 原有主从架构 ：
  • 主节点：6379
  • 从节点：6380、6381
• 哨兵部署规划 ：
  • 哨兵节点1：26379
  • 哨兵节点2：26380
  • 哨兵节点3：26381
• 核心作用：监控主从节点状态、主节点故障时自动选举新主节点、客户端统一发现主节点。

1.2 前置检查

部署哨兵前，必须保证原有一主二从架构正常运行：

# 检查所有Redis实例状态
redis-cli -p 6379 info replication
redis-cli -p 6380 info replication
redis-cli -p 6381 info replication

✅ 确认：

• 主节点 6379 角色为 master，且 connected_slaves:2
• 从节点 6380/6381 角色为 slave，且 master_link_status:up

---

二、步骤1：创建哨兵目录与配置文件拷贝

2.1 创建哨兵专属目录

为三个哨兵节点创建独立目录，实现配置、日志、数据隔离：

mkdir -p /usr/local/redis/sentinel/26379
mkdir -p /usr/local/redis/sentinel/26380
mkdir -p /usr/local/redis/sentinel/26381

目的：每个哨兵节点独立存储配置文件、日志文件，避免多实例冲突。

2.2 拷贝原生哨兵配置文件

Redis 安装目录下自带 sentinel.conf 模板，拷贝至三个哨兵目录：

# 找到原生配置文件（和redis.conf同级）
cp /usr/local/redis/sentinel.conf /usr/local/redis/sentinel/26379/
cp /usr/local/redis/sentinel.conf /usr/local/redis/sentinel/26380/
cp /usr/local/redis/sentinel.conf /usr/local/redis/sentinel/26381/

目的：基于官方模板修改，保证哨兵服务稳定运行。

---

三、步骤2：逐个配置哨兵节点（核心）

哨兵节点的核心配置逻辑一致，仅需修改端口、PID、日志等唯一标识，监控规则保持统一。

3.1 哨兵1（端口 26379）配置

编辑配置文件：

vim /usr/local/redis/sentinel/26379/sentinel.conf

修改以下配置项：

# 1. 设置哨兵端口（默认26379，第一个哨兵使用默认值）
port 26379
# 目的：指定当前哨兵节点的服务端口

# 2. 开启后台运行
daemonize yes
# 目的：哨兵以守护进程后台启动，不占用终端窗口

# 3. 独立PID文件
pidfile /var/run/redis-sentinel-26379.pid
# 目的：每个哨兵节点独有PID文件，防止多实例启动冲突

# 4. 独立日志文件
logfile "/usr/local/redis/sentinel/26379/sentinel.log"
# 目的：日志单独存放，方便排查哨兵运行问题

# 5. 哨兵工作目录
dir /usr/local/redis/sentinel/26379
# 目的：指定哨兵持久化数据存放目录

# ========== 核心监控配置 ==========
# 格式：sentinel monitor 集群名 主节点IP 主节点端口 法定票数
sentinel monitor mymaster 127.0.0.1 6379 2
# 目的：声明当前哨兵监控的主节点，法定票数为2（3个哨兵中至少2个判定主节点宕机，才执行故障转移）

# 主节点失联主观下线判定时间（单位：毫秒）
sentinel down-after-milliseconds mymaster 30000
# 目的：哨兵30秒未收到主节点响应，判定为主观下线

# 故障转移后，同时同步主数据的从节点数量
sentinel parallel-syncs mymaster 1
# 目的：限制同时同步的从节点数，避免主节点压力过大

# 故障转移超时时间
sentinel failover-timeout mymaster 180000
# 目的：故障转移过程超时后自动重试

# 补充：主节点设置密码时，需添加以下配置
# sentinel auth-pass mymaster 你的主节点密码

3.2 哨兵2（端口 26380）配置

编辑配置文件：

vim /usr/local/redis/sentinel/26380/sentinel.conf

仅修改端口、PID、日志、目录，监控配置与哨兵1保持一致：

port 26380
daemonize yes
pidfile /var/run/redis-sentinel-26380.pid
logfile "/usr/local/redis/sentinel/26380/sentinel.log"
dir /usr/local/redis/sentinel/26380

# 监控配置与哨兵1完全一致
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

3.3 哨兵3（端口 26381）配置

编辑配置文件：

vim /usr/local/redis/sentinel/26381/sentinel.conf

port 26381
daemonize yes
pidfile /var/run/redis-sentinel-26381.pid
logfile "/usr/local/redis/sentinel/26381/sentinel.log"
dir /usr/local/redis/sentinel/26381

# 监控配置统一
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

---

四、步骤3：启动所有哨兵节点

注意：必须先启动Redis主从节点，再启动哨兵节点，否则哨兵会无法识别主节点。

4.1 启动命令

# 启动哨兵1（26379）
redis-sentinel /usr/local/redis/sentinel/26379/sentinel.conf

# 启动哨兵2（26380）
redis-sentinel /usr/local/redis/sentinel/26380/sentinel.conf

# 启动哨兵3（26381）
redis-sentinel /usr/local/redis/sentinel/26381/sentinel.conf

4.2 校验进程状态

ps -ef | grep redis

✅ 预期结果：共6个进程，包含3个Redis实例 + 3个哨兵实例。

---

五、步骤4：哨兵状态校验（带完整输出）

连接任意哨兵节点，查看监控状态：

redis-cli -p 26379

5.1 查看哨兵整体信息

执行命令：

127.0.0.1:26379> info sentinel

✅ 正常输出核心片段：

# Sentinel
sentinel_masters:1
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

解读：

• status=ok：主节点状态正常
• slaves=2：哨兵识别到2个从节点
• sentinels=3：3个哨兵节点互相发现，集群正常

5.2 查看主节点详细信息

127.0.0.1:26379> sentinel masters

5.3 查看从节点信息

127.0.0.1:26379> sentinel slaves mymaster

5.4 查看其他哨兵节点

127.0.0.1:26379> sentinel sentinels mymaster

---

六、步骤5：模拟主节点故障，测试自动故障转移

6.1 手动关闭原主节点 6379

redis-cli -p 6379 shutdown

6.2 观察哨兵故障转移过程

等待30秒（对应 down-after-milliseconds 配置时间），哨兵会自动执行以下操作：

1. 判定原主节点主观下线
2. 3个哨兵协商判定客观下线
3. 从 6380 和 6381 中选举新主节点（例如 6381）
4. 剩余从节点自动配置为新主节点的从节点
5. 哨兵配置文件自动更新主节点地址

6.3 校验故障转移结果

执行命令：

redis-cli -p 26379 info sentinel

✅ 预期输出：

master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=2,sentinels=3

解读：主节点地址已更新为 127.0.0.1:6381，故障转移成功。

6.4 校验新主从关系

# 查看新主节点 6381 状态
redis-cli -p 6381 info replication
# 预期：role:master，connected_slaves:1

# 查看从节点 6380 状态
redis-cli -p 6380 info replication
# 预期：role:slave，master_port:6381

6.5 恢复原主节点 6379

redis-server /usr/local/redis/replication/6379/redis.conf

✅ 预期结果：6379 会自动成为新主节点 6381 的从节点，哨兵配置文件会自动更新该节点信息。

---

七、高频问题与避坑指南

7.1 为什么关闭 6379 后，哨兵显示 slaves=2？

• slaves=2 是哨兵记录的集群中从节点总数，不是当前在线从节点数。
• 哨兵会记录所有历史从节点，当原主节点重启后，会自动加入集群成为从节点，恢复 slaves=2 在线状态。

7.2 哨兵节点数量为什么建议为奇数？

• 哨兵集群采用投票机制，法定票数需满足 哨兵总数/2 + 1。
• 3个哨兵时，法定票数设为2，可避免"脑裂"问题，保证故障转移的一致性。

7.3 主节点设置密码后，哨兵需要额外配置吗？

• 必须在所有哨兵节点配置 sentinel auth-pass mymaster 主节点密码，否则哨兵无法连接主节点，会误判为故障。

7.4 单机测试时，127.0.0.1 可以正常使用吗？

• 单机环境下，127.0.0.1 可正常使用；多机器部署时，需改为主节点真实IP，并开启主节点 bind 0.0.0.0 允许外部访问。

---

八、哨兵常用运维命令

# 1. 停止指定哨兵节点
redis-cli -p 26379 shutdown

# 2. 查看所有Redis+哨兵进程
ps -ef | grep redis

# 3. 强制杀死哨兵进程（优雅停止失败时使用）
kill -9 哨兵进程PID

# 4. 手动故障转移（主动切换主节点）
redis-cli -p 26379 sentinel failover mymaster

---

九、核心配置速记

配置项	作用	关键说明
port	哨兵节点端口	多哨兵必须唯一，避免冲突
sentinel monitor	监控主节点配置	集群名统一，法定票数为哨兵总数/2+1
sentinel down-after-milliseconds	主观下线判定时间	单机测试建议30000ms，根据业务场景调整
daemonize yes	后台运行	生产环境必须开启

---

至此，基于一主二从架构的Redis哨兵模式部署完成，实现了主节点故障自动转移，提升了Redis服务的高可用性。