前言
在生产环境中，除了采用持久化方式实现 Redis 的高可用性，还可以采用主从复制、哨兵模式和 Cluster 集群的方法确保数据的持久性和可靠性。
目录
一、主从复制
1. 概述
主从复制是高可用 Redis 的基础，将一台 Redis 服务器的数据复制到其它的 Redis 服务器。前者 为主 master，后者为 slave，单向从主到从；主可以有多个从，从只能有一个主。
2. 作用
① 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
② 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余
③ 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量
④ 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础
3. 主从复制流程
① 启动一个 slave 机器进程，从 redis 会向主发送 sync 同步数据请求
② 主 redis 会 fork 一个子进程，会产生 rdb 文件（完全备份文件的过程）
③ rdb 文件的持久化完成后，主 redis 会将 rdb 文件和缓存起来的命令推送给从服务器
④ 复制、推送完后后，主 redis 会持续的同步操作命令，利用 aof（增备）持久化功能
⑤ 在下一台 redis 接入主从复制之前，会持续利用 aof 的方式同步数据给从服务器
4. 部署
环境准备：关闭防火墙与核心防护
- master节点： 192.168.190.100
- slave1节点： 192.168.190.101
- slave2节点： 192.168.190.102
4.1 安装 redis
yum install -y gcc gcc-c++ make
cd /opt/
wget http://download.redis.io/releases/redis-5.0.7.tar.gz
tar zxvf redis-5.0.7.tar.gz
cd redis-5.0.7/
make -j 2 && make prefix=/usr/local/redis install
cd /opt/redis-5.0.7/utils
./install_server.sh
......
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server
ln -s /usr/local/redis/bin/* /usr/local/bin/
4.2 编辑 master 节点配置文件
[root@master ~]# vim /etc/redis/6379.conf
70 bind 0.0.0.0 # 修改监听地址为0.0.0.0
137 daemonize yes # 开启守护进程
172 logfile /var/log/redis_6379.log # 指定日志文件目录
264 dir /var/lib/redis/6379 # 指定工作目录
700 appendonly yes # 开启AOF持久化功能
[root@master ~]# /etc/init.d/redis_6379 restart选择配置 systemd 管理服务：
[root@master ~]# vim /usr/lib/systemd/system/redis.service
[Unit] # 包含了关于服务单元的描述信息
Description=Redis Server # 描述服务
After=network.target # 指定了服务应该在网络服务启动后启动
[Service] # 包含了关于服务如何运行的配置信息
PIDFile=/var/run/redis_6379.pid # 方便使用pid号进行操作
ExecStart=/usr/local/redis/bin/redis-server /etc/redis/6379.conf # 指定了启动Redis服务时要执行的命令
ExecStop=/usr/local/redis/bin/redis-cli shutdown # 指定了停止Redis服务时要执行的命令，这里是使用redis-cli发送shutdown命令
Restart=always # 指定了服务在意外终止时应该自动重新启动
[Install] # 定义了如何安装这个服务
WantedBy=multi-user.target # 安装字符界面，指定了在多用户模式下启用这个服务
[root@master ~]# systemctl daemon-reload
[root@localhost ~]# systemctl start redis.service
[root@localhost ~]# systemctl status redis.service
● redis.service - Redis Server
Loaded: loaded (/usr/lib/systemd/system/redis.service; disabled; vendor preset: disabled)
Active: active (running) since 三 2024-04-03 17:56:18 CST; 6s ago
Main PID: 5473 (redis-server)
4.3 编辑 slave 节点配置文件
[root@slave1 ~]# vim /etc/redis/6379.conf
70 bind 0.0.0.0 # 修改监听地址为0.0.0.0
137 daemonize yes # 开启守护进程
172 logfile /var/log/redis_6379.log # 指定日志文件目录
264 dir /var/lib/redis/6379 # 指定工作目录
288 replicaof 192.168.190.100 6379 # 指定要同步的Master节点IP和端口
700 appendonly yes # 开启AOF持久化功能
[root@slave1 ~]# scp -p /etc/redis/6379.conf root@192.168.190.102:/etc/redis/
/etc/init.d/redis_6379 restart # 两台从服务器均重启redis服务4.4 验证主从效果
① 在 master 节点上验证从节点
[root@master ~]# redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.190.101,port=6379,state=online,offset=98,lag=0
slave1:ip=192.168.190.102,port=6379,state=online,offset=98,lag=1
[root@master ~]# tail -f /var/log/redis_6379.log
② 在 master 数据库存放数据
[root@master ~]# redis-cli
127.0.0.1:6379> set a 1
OK
127.0.0.1:6379> get a
"1"
③ 在 slave 数据库获取数据
[root@slave1 ~]# redis-cli
127.0.0.1:6379> get a
"1"
[root@slave2 ~]# redis-cli
127.0.0.1:6379> get a
"1"
# 至此实现主从复制二、哨兵模式
1. 概述
主从切换需要人工干预，为了解决主从复制的缺点，在主从复制的基础上，哨兵引入了主节点的自动故障转移。
2. 结构
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 redis 节点，不存储数据
数据节点：主节点和从节点都是数据节点
2. 功能与原理
哨兵（sentinel）是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
3. 作用
监控：哨兵会不断地检查主节点和从节点是否运作正常（哨兵间也会监测）
自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将其中一个从节点升级为新的主节点，并让其它从节点改为复制新的主节点
通知（提醒）：哨兵可以将故障转移的结果发送给客户端
4. 故障转移机制
① 由哨兵节点定期监控发现主节点是否出现了故障，每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次 ping 命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息，那么这个哨兵就会认为这个主节点主观下线了（单方面的）。当超过半数哨兵节点认为该主节点主观下线了，这样就客观下线了。
② 当主节点出现故障，此时哨兵节点会通过 Raft 算法（选举算法）实现选举机制共同选举出一个哨兵节点为 leader，来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。
③ 由 leader 哨兵节点执行故障转移，过程如下：
- 将某一个从节点升级为新的主节点，让其它从节点指向新的主节点
- 若原主节点恢复也变成从节点，并指向新的主节点
- 通知客户端主节点已经更换
注意：客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
5. 主节点选举的过程
监控对象：
- 哨兵对主从复制集群进行监控：所有redis数据节点
- 哨兵与哨兵之间进行相互监控：哨兵彼此
监控目的：
- 哨兵监控所有的 redis 数据库的目的：为了实现故障自动故障切
- 哨兵与哨兵之间的监控目的：检测彼此的存活状态
故障切换过程：
① 当master 挂掉，哨兵会及时发现之后 进行投票机制，选发现，举出一个新的master服务器（一定是基数）
② 完成 salve 到 master 的切换
③ 完成其他的从服务器对新的 master 配置
6. 搭建 redis 哨兵模式
6.1 所有节点修改哨兵模式配置文件
vim /opt/redis-5.0.7/sentinel.conf
17 protected-mode no # 关闭保护模式
21 port 26379 # Redis哨兵默认的监听端口
26 daemonize yes # 指定sentinel为后台启动
36 logfile "/var/log/sentinel.log" # 指定日志存放路径
65 dir /var/lib/redis/6379 # 指定数据库存放路径
84 sentinel monitor mymaster 192.168.190.100 6379 2 # 修改master ip
# 指定该哨兵节点监控192.168.190.100:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
113 sentinel down-after-milliseconds mymaster 30000 # 判定服务器down掉的时间周期，默认30000毫秒（30秒）
146 sentinel failover-timeout mymaster 180000 # 故障节点的最大超时时间为180000（180秒）6.2 启动哨兵模式
注意：先启 master，再启 slave
[root@master ~]# cd /opt/redis-5.0.7/
[root@master redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 6728
[root@slave1 ~]# cd /opt/redis-5.0.7/
[root@slave1 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 41954
[root@slave2 ~]# cd /opt/redis-5.0.7/
[root@slave2 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 8273
6.3 查看哨兵信息
[root@slave2 ~]# redis-cli -p 26379 info Sentinel
# 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.190.100:6379,slaves=2,sentinels=3
# 名为 "mymaster" 的主节点的详细信息。它显示该主节点的状态正常（status=ok），地址为 192.168.190.100:6379，有 2 个从节点（slaves）和 3 个 Sentinel。6.4 查看日志并模拟 master 故障
[root@master ~]# systemctl stop redis.service[root@slave2 ~]# tail -f /var/log/sentinel.log
8261:X 03 Apr 2024 19:47:03.639 # +config-update-from sentinel f6084d790599b7c806cde643fcf083df6f782182 192.168.190.101 26379 @ mymaster 192.168.190.100 6379
# 表示一个 Sentinel 实例收到了来自另一个 Sentinel 实例的配置更新
8261:X 03 Apr 2024 19:47:03.639 # +switch-master mymaster 192.168.190.100 6379 192.168.190.102 6379
# 名为 "mymaster" 的主节点从地址 192.168.190.100:6379 切换到了新地址 192.168.190.102:6379。这通常代表着故障转移（failover）的发生，即主节点切换到了另一个地址上
8261:X 03 Apr 2024 19:47:03.640 * +slave slave 192.168.190.101:6379 192.168.190.101 6379 @ mymaster 192.168.190.102 6379
8261:X 03 Apr 2024 19:47:03.640 * +slave slave 192.168.190.100:6379 192.168.190.100 6379 @ mymaster 192.168.190.102 6379
# 表示两个从节点已经成功地重新连接到新的主节点地址 192.168.190.102:6379。
8261:X 03 Apr 2024 19:47:33.715 # +sdown slave 192.168.190.100:6379 192.168.190.100 6379 @ mymaster 192.168.190.102 6379
6.5 再次查看哨兵信息
[root@master ~]# redis-cli -p 26379 info Sentinel
# 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.190.102:6379,slaves=2,sentinels=3