1.前言

Redis传统的主从复制架构虽然提高了读性能，但主节点故障后需要人工干预，这可能导致服务中断。 为了解决这个问题，Redis提供了哨兵模式（Sentinel模式），实现了故障自动转移（Failover）和高可用性。

本文将以Redis 1主2从3哨兵模式为例，详细介绍其搭建方法、运行机制以及高可用验证，帮助读者理解并掌握哨兵模式的实际应用。

2.硬件资源

3.服务搭建

3.1 下载并编译redis

• 下载redis

https://download.redis.io/releases/ 下载所需版本
wget http://download.redis.io/releases/redis-6.2.0.tar.gz
tar -xzf redis-6.2.0.tar.gz
mv redis-6.2.0 redis
cd redis

• 编译、安装redis

make ## 编译
make install ## 安装

• 在另外2台机器上执行同样的操作,完成redis服务安装

3.2 按照第2章规划搭建1主2从3哨兵redis哨兵集群服务

• 在第1台虚机上分别配置master和sentinel哨兵实例的配置

[root@localhost redis]# pwd
/opt/install/redis
[root@localhost redis]# ls -lt |grep redis.conf
-rw-r--r--.  1 root root   668 Dec 31 06:41 redis.conf.master
-rw-r--r--.  1 root root   859 Dec 31 06:41 redis.conf.sentinel
-rw-rw-r--.  1 root root 92222 Feb 23  2021 redis.conf

master实例配置如下

# 后台启动
daemonize yes
# 监听所有 IP，允许外部连接
bind 0.0.0.0
# 监听端口
port 6379

# 设置主节点的认证密码
requirepass 123456
masterauth "123456"
# 启用 RDB 持久化（根据需要配置）
save 900 1
save 300 10
save 60 10000

# 启用 AOF 持久化
appendonly yes
appendfsync everysec

# 日志设置
loglevel notice
logfile "/var/log/redis/redis-master.log"

# 配置最大客户端连接数
maxclients 10000

sentinel1实例配置如下

# 主节点如果设置了密码，就在这里配置
sentinel auth-pass mymaster 123456
# 后台启动
daemonize yes
# 监听所有 IP，允许外部连接
bind 0.0.0.0
port 26379
sentinel monitor mymaster 11.0.1.101 6379 2

loglevel debug
logfile "/var/log/redis/sentinel.log"

• 在第2台虚机上分别配置slave1和sentinel2实例的配置

[root@localhost redis]# pwd
/opt/install/redis
[root@localhost redis]# ls -lt|grep redis.conf
-rw-r--r--.  1 root root   870 Dec 30 21:48 redis.conf.sentinel
-rw-r--r--.  1 root root   610 Dec 30 21:48 redis.conf.slave
-rw-rw-r--.  1 root root 92222 Feb 23  2021 redis.conf
[root@localhost redis]#

slave1实例配置如下

masterauth "123456"
# 当前结点的密码
requirepass 123456
# # 后台启动
daemonize yes
#
# 监听所有 IP，允许外部连接
bind 0.0.0.0
port 6379

# 设置主节点的认证密码

# 启用持久化（与主节点保持一致）
appendonly yes
appendfsync everysec

# 日志设置
loglevel notice
logfile "/var/log/redis/redis-slave.log"

sentinel2实例配置如下

# 主节点如果设置了密码，就在这里配置
sentinel auth-pass mymaster 123456
# # 后台启动
daemonize yes
#
# sentinel2.conf
port 26379
# 哨兵 2 监听的端口号
bind 0.0.0.0
sentinel monitor mymaster 11.0.1.101 6379 2

loglevel debug
logfile "/var/log/redis/sentinel.log"

• 在第3台虚机上分别配置slave2和sentinel3实例的配置

[root@localhost redis]# pwd
/opt/install/redis
[root@localhost redis]# ls -lt |grep redis
-rw-r--r--.  1 root root   911 Dec 30 21:48 redis.conf.sentinel
-rw-r--r--.  1 root root   586 Dec 30 21:48 redis.conf.slave
-rw-rw-r--.  1 root root 92222 Feb 23  2021 redis.conf

slave2实例配置如下

masterauth "123456"
# 当前结点的密码
requirepass 123456
# # 后台启动
daemonize yes
#
# 监听所有 IP，允许外部连接
bind 0.0.0.0
port 6379

# 设置主节点的认证密码

# 启用持久化（与主节点保持一致）
appendonly yes
appendfsync everysec

# 日志设置
loglevel notice
logfile "/var/log/redis/redis-slave.log"

sentinel3实例配置如下

# 主节点如果设置了密码，就在这里配置
sentinel auth-pass mymaster 123456
# # 后台启动
daemonize yes
#
# 监听所有 IP，允许外部连接
bind 0.0.0.0
#
# sentinel3.conf
port 26379
# 哨兵 3 监听的端口号

sentinel monitor mymaster 11.0.1.101 6379 2
loglevel debug
logfile "/var/log/redis/sentinel.log"

• 在三台虚机上依次启动redis主从实例服务和哨兵实例服务 在11.0.1.99上启动master节点

redis-server redis.conf.master

在11.0.1.100上启动slave1节点

redis-server redis.conf.slave

在11.0.1.101上启动slave2节点

redis-server redis.conf.slave

通过命令行连接redis主节点,info命令查看redis主从信息

• 在三台虚机上依次启动redis哨兵实例服务

在11.0.1.99上启动sentinel1节点

redis-server redis.conf.sentinel --sentinel

在11.0.1.100上启动sentinel2节点

redis-server redis.conf.sentinel --sentinel

在11.0.1.101上启动sentinel3节点

redis-server redis.conf.sentinel --sentinel

通过命令行连接redis哨兵,info命令查看redis哨兵集群信息

3.3 验证redis哨兵集群自动故障转移功能

• 杀掉master节点,redis哨兵集群自动实现主从切换

[root@localhost redis]# ps -ef|grep redis
root      18152      1  2  2024 ?        00:21:21 redis-server 0.0.0.0:6379
root      18163      1  3  2024 ?        00:39:00 redis-server 0.0.0.0:26379 [sentinel]
root      24828  24777  0 05:07 pts/0    00:00:00 redis-cli -p 6379
root      29379  28048  0 11:54 pts/3    00:00:00 grep --color=auto redis
[root@localhost redis]# kill -9 18152

4.总结

如果系统规模较小，追求高可用性但对分布式存储和一致性要求不高，哨兵模式是一个成本较低、易于实施的选择。

部署时注意事项

• 确保哨兵数量为奇数（至少 3 个）以避免脑裂。
• 根据业务场景合理配置quorum和failover-timeout参数。
• 定期检查主从同步延迟和数据一致性。