Redis-sentinel（哨兵模式）的搭建步骤及相关知识

1、什么是redis-sentinel，和redis主从复制相比，它具有什么优势

1.1、redis主从复制

Redis主从复制是一种用于数据冗余和可伸缩性的机制，它将一台Redis服务器的数据复制到其他Redis服务器。在这种模式下，数据会实时地从一个主节点（Master）同步到一个或多个从节点（Slave）。
然而，单纯的redis主从复制存在一个明显的缺点——即当主节点（Master）发生故障不可用时，尽管数据因为实时的进行复制而不会丢失（或者丢失极少），但将从节点（Slave）升级为主节点（Master）需要人工介入，手动进行切换。因此，这不但增加了运维的人工成本，并且还无法保障业务连续性。综上，这也是redis主从复制作为redis的冗余方案之一，最大的一个制约因素。

1.2、redis-sentinel的优势

Redis-Sentinel是Redis官方推荐的高可用性（HA）解决方案，从本质上来说，Redis-Sentinel是一个独立运行的进程，专门用于监控Redis集群中的主从节点。当主节点（Master）出现故障时，Redis-Sentinel能够自动选择并提升一个从节点（Slave）为新的主节点，以保证服务的持续可用性，Redis-Sentinel通过心跳机制检测节点的运行状态，并使用投票算法进行故障判断和主备切换决策。所以，redis-sentinel方案解决的是redis主从复制无法自动进行主从切换（故障转移）的问题。

2、搭建示例

2.1、实验拓扑

2.2、实施步骤

2.2.1、部署“一主二从”式的redis主从复制架构

【redis-master节点（操作系统为OpenEuler-22.03 -LTS-SP2）】
1、通过命令“yum install redis”安装redis；
2、通过命令“systemctl status redis”查看redis状态，保证安装完成后redis进程处于关闭的状态；

3、通过命令“touch /etc/redis-master.conf”创建一个配置文件，并在配置文件中输入以下内容：

port 6379
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/var/log/redis_6379.log"
dir "/var/lib/redis"

# 开启持久化
save 900 1
save 300 10
save 60 10000

# 关闭保护模式
protected-mode no

# 绑定IP地址
bind 127.0.0.1 192.168.174.136

配置文件内容的含义如下：

【redis-slave节点（操作系统为OpenEuler-22.03 -LTS-SP2）】
1、通过命令“yum install redis”安装redis；
2、通过命令“systemctl status redis”查看redis状态，保证安装完成后redis进程处于关闭的状态；

3、通过命令“touch /etc/redis-master.conf”创建一个配置文件，并在配置文件中输入以下内容（与Master节点的配置文件相比，绝大部分内容一样，只是绑定的IP地址不同，且多出了一个slaveof参数用于指向Master节点的IP地址，代表自己是slave节点）：

port 6379
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/var/log/redis_6379.log"
dir "/var/lib/redis"

# 开启持久化
save 900 1
save 300 10
save 60 10000

# 关闭保护模式
protected-mode no

# 绑定IP地址
bind 127.0.0.1 192.168.174.131

#指定主节点
slaveof 192.168.174.136 6379

【redis-slave节点（操作系统为OpenEuler-22.03 -LTS-SP2）】
1、通过命令“yum install redis”安装redis；
2、通过命令“systemctl status redis”查看redis状态，保证安装完成后redis进程处于关闭的状态；

3、通过命令“touch /etc/redis-master.conf”创建一个配置文件，并在配置文件中输入以下内容（与Master节点的配置文件相比，绝大部分内容一样，只是绑定的IP地址不同，且多出了一个slaveof参数用于指向Master节点的IP地址，代表自己是slave节点）：

port 6379
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/var/log/redis_6379.log"
dir "/var/lib/redis"

# 开启持久化
save 900 1
save 300 10
save 60 10000

# 关闭保护模式
protected-mode no

# 绑定IP地址
bind 127.0.0.1 192.168.174.130

#指定主节点
slaveof 192.168.174.136 6379

2.2.2、部署redis-sentinel节点

【redis-sentinel节点（操作系统为debian-12）】
1、通过命令“apt install redis-sentinel”安装redis-sentinel（debian系Linux的redis-sentinel都需要单独进行安装，而红帽系Linux系统中的redis-sentinel已经集成在redis安装包及其依赖中，无需单独安装）；
2、通过以下命令创建“redis-sentinel-1.conf 、redis-sentinel-2.conf 、redis-sentinel-3.conf”三个配置文件：

touch /etc/redis-sentinel-1.conf
touch /etc/redis-sentinel-2.conf
touch /etc/redis-sentinel-3.conf

3、在三个配置文件中分别加入以下内容（3个文件除端口号、进程文件名和日志文件名设定不同，其余配置一样）：
【redis-sentinel-1.conf】

port 26379
daemonize yes
pidfile /var/run/redis-sentinel-1.pid
logfile /var/log/redis-sentinel-1.log
dir /var/lib/redis

# 监控主服务器
sentinel monitor mymaster 192.168.174.136 6379 2

# 判断主服务器下线的时间
sentinel down-after-milliseconds mymaster 10000

# 故障转移的超时时间
sentinel failover-timeout mymaster 10000

# 在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1

【redis-sentinel-2.conf】

port 26380
daemonize yes
pidfile /var/run/redis-sentinel-2.pid
logfile /var/log/redis-sentinel-2.log
dir /var/lib/redis

# 监控主服务器
sentinel monitor mymaster 192.168.174.136 6379 2

# 判断主服务器下线的时间
sentinel down-after-milliseconds mymaster 10000

# 故障转移的超时时间
sentinel failover-timeout mymaster 10000

# 在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1

【redis-sentinel-3.conf】

port 26381
daemonize yes
pidfile /var/run/redis-sentinel-3.pid
logfile /var/log/redis-sentinel-3.log
dir /var/lib/redis

# 监控主服务器
sentinel monitor mymaster 192.168.174.136 6379 2

# 判断主服务器下线的时间
sentinel down-after-milliseconds mymaster 10000

# 故障转移的超时时间
sentinel failover-timeout mymaster 10000

# 在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1

2.2.3、启动相关服务

1、依次在对应节点输入以下命令来启动服务：
【redis-master节点】

redis-server /etc/redis-master.conf &

【两个redis-slave节点】

redis-server /etc/redis-slave.conf &

【redis-sentinel节点】

redis-sentinel /etc/redis/redis-sentinel-1.conf &
redis-sentinel /etc/redis/redis-sentinel-2.conf &
redis-sentinel /etc/redis/redis-sentinel-3.conf &

3、分别在以下节点验证主从复制和redis-sentinel是否正常
【redis-master节点】
通过命令“netstat -lnpt | grep 6379”查看端口监听状态：

通过命令“redis-cli -p 6379 info replication”查看主节点（Master）是否发现了两个从节点（Slave）：

【两个redis-slave节点】
通过命令“netstat -lnpt | grep 6379”查看端口监听状态：

通过命令“redis-cli -p 6379 info replication”查看从节点（Master）指向的主节点（Master）信息和状态：

【redis-sentinel节点】
通过命令“netstat -lnpt”查看端口监听状态：

通过命令“redis-cli -p 26379 info sentinel”查看当前sentinel进程的节点监控信息（-p参数下除26379端口外，也可以设置为26380和26381端口）：

3、验证数据同步和故障转移

3.1数据同步

在Master节点进行如下操作：

分别查看两个slave节点：

3.2、验证故障转移

在Master节点上输入命令“killall redis-server”杀死redis-server进程：

在sentinel节点上输入命令“redis-cli -p 26379 info sentinel”查看Master节点的自动变化情况：

需要注意的是，如果此时原有的136节点恢复了正常服务，它会变为当前主节点（130节点）的从节点，而不会抢占为主节点。
在redis主从复制中，某个节点是主节点还是从节点，是由配置文件的内容决定的，而当主节点故障发生时，人工干预的方式是去修改配置文件，redis-seninel只是将这一过程有监听程序自动化了，而不需要人工干预，通过查看136节点（原来的主节点）的配置文件，我们可以看到这个过程：

4、实验注意事项

4.1、各个节点之间的redis版本必须严格保持一致

各个节点之间的redis版本必须严格保持一致，如果不一致，例如redis4和redis5之间构成了一个redis-sentinel架构，虽然无故障发生时，数据同步时正常的，但故障发生后，重新启用故障节点的进程，该节点就会出现数据无法恢复的情况，也无法通过同步复制写入新的数据。通过查看相关日志（对应redis节点配置文件中logfile参数所定义的日志文件），可以发现是因为版本之间的不兼容，导致RDB文件中的数据无法被正确读取和恢复：

4.2、已知在OpenEuler系统中，哨兵模式无法转移故障的场景

通过在OpenEuler-22.03 -LTS-SP2实验中发现，如果redis-sentinel进程和redis主节点或从节点（redis-server进程）都在同一台服务器上，当人为将主节点上redis-server进程杀死时，尽管三个位于各自主从节点上的redis-sentinel进程都会各自将Master视作主观下线，但无法触发客观下线的投票，或故障转移的投票被否决，这会导致故障无法转移而业务中断。
当然这样的部署方式本身就存在不合理的地方，因为将redis-sentinel进程和redis-server进程部署在同一台服务器的做法无法发挥出该有的高可用特性，但在实验过程中，出现了这样的情况，暂不清楚其他的Linux系统和redis版本是否也会出现这样的现象。

5、相关知识

5.1、主观下线和客观下线

在Redis中，主观下线和客观下线是哨兵（Sentinel）机制中的两个重要概念，用于判断Redis实例（特别是主服务器）的健康状态和是否需要进行故障转移。

• 主观下线（Subjective Down,
  SDOWN）：是指某个哨兵节点独立地认为某个Redis实例（包括主服务器或从服务器）已经不可达；
• 客观下线（Objective Down,
  ODOWN）：是指多个哨兵节点都认为某个Redis实例（特指主服务器）已经不可达，并且这一判断达到了法定人数（quorum）的要求（触发投票机制）。

在redis-sentinel的相关日志中，其实就可以看到redis-sentinel进程大量判断某个节点主观下线或者客观下线的相关记录：

5.2、redis的持久化

Redis 持久化是指将 Redis 内存中的数据存储到磁盘上，以确保在 Redis 服务器重启或发生其他故障时，数据不会丢失。Redis 提供了两种主要的持久化方式：RDB（Redis DataBase）和 AOF（Append Only File）。
【RDB 持久化】
RDB 持久化通过创建并保存 Redis 数据集的快照来工作。在指定的时间间隔内，执行数据集快照，并生成一个 .rdb 文件。Redis 重启时，通过加载这个 .rdb 文件来恢复数据。其具有以下特点：

• RDB 是一个紧凑的二进制文件，保存了 Redis 在某个时间点上的数据集。
• RDB 持久化非常适合用于备份，全量复制等场景。
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
• RDB 会丢失最后一次快照之后写入的数据。

【AOF 持久化】
AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库状态的。当 Redis 服务器重启时，会重新执行这些写命令来恢复数据。其具有以下特点：

• AOF 持久化以日志的形式记录 Redis 所执行的写命令，因此它可以保存更多的数据。
• AOF 文件的更新频率通常比 RDB 文件的更新频率高，因为 AOF 需要记录每条写命令。
• AOF 持久化的写入性能通常比 RDB 持久化低，因为需要记录每条写命令。
• AOF 持久化在数据恢复时，需要重放所有写命令，因此恢复速度通常比 RDB 慢。
• AOF 提供了三种不同的写回策略（always, everysec, no），可以根据应用的需求进行调整。