redis高可用-主从复制和哨兵模式

文章目录

前言
一、持久化
二、主从复制
三、哨兵模式
四、redis主从复制部署
五、哨兵模式部署（所有节点）
总结

前言

本文围绕 Redis 高可用核心技术，系统解析持久化、主从复制与哨兵模式的原理及价值，结合实操部署与故障验证，助力快速落地稳定可靠的 Redis 架构。

一、持久化

1、持久化介绍

持久化是最简单的高可用方法，主要作用是数据备份，即将数据存

储在硬盘，保证数据不会因进程退出而丢失。

2、rdb持久化

2.1、rdb快照

定期把数据快照保存到磁盘

优点：文件小，恢复快。

缺点：可能丢几分钟数据。

2.2、触发条件

手动触发：（使用bgsave）

在redis交互页面输入：bgsave或者save即可触发快照，生成rdb文件

save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。

而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。

总结：因此save已基本被废弃，线上环境要杜绝save的使用。

自动触发：

vim /etc/redis/6379.conf

bash 复制代码

save m n
--219行--以下三个save条件满足任意一个时，都会引起bgsave的调用
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
--242行--是否开启RDB文件压缩
rdbcompression yes

自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。

其他触发快照的场景：

bash 复制代码

shutdown # redis服务优雅退出,会触发快照
stop # redis被关闭，可能会触发快照，不稳定
exit # 退出redis-cli，服务没关闭
quit # 退出redis-cli，服务没关闭

2.3、bgsave流程原理

Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。 bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
父进程fork后，bgsave命令返回"Background saving started"信息并不再阻塞父进程，并可以响应其他命令
子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
子进程发送信号给父进程表示完成，父进程更新统计信息

3、AOF持久化

3.1、aof介绍

RDB持久化是将进程数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录；当Redis重启时再次执行AOF文件中的命令来恢复数据。与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

3.2、开启AOF

bash 复制代码

# Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置
vim /etc/redis/6379.conf
--700行--修改，开启AOF
appendonly yes
--704行--指定AOF文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
  
/etc/init.d/redis_6379 restart

二、主从复制

1、主从复制介绍

一主多从，主写从读。

主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。

主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。

缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

2、主从复制作用

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

3、主从复制流程

（1）若启动一个Slave机器进程，则它会向Master机器发送一个"sync command"命令，请求同步连接。

（2）无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中（执行rdb操作），同时Master还会记录修改数据的所有命令并缓存在数据文件中。

（3）后台进程完成缓存操作之后，Master机器就会向Slave机器发送数据文件，Slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接。

（4）Master机器收到Slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个Slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。

三、哨兵模式

1、哨兵模式介绍

主机宕机，自动切换到从机。

2、哨兵模式原理

哨兵(sentinel):是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。

3、哨兵模式作用

监控：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其它从节点改为复制新的主节点。
通知（提醒）：哨兵可以将故障转移的结果发送给客户端。

4、故障转移机制

1.由哨兵节点定期监控发现主节点是否出现了故障

每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息，那么这个哨兵就会认为这个主节点主观下线了（单方面的）。当超过半数哨兵节点认为该主节点主观下线了，这样就客观下线了。

2.当主节点出现故障，此时哨兵节点会通过Raft算法（选举算法）实现选举机制共同选举出一个哨兵节点为leader，来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。

3.由leader哨兵节点执行故障转移，过程如下：

将某一个从节点升级为新的主节点，让其它从节点指向新的主节点；
若原主节点恢复也变成从节点，并指向新的主节点；
通知客户端主节点已经更换。
需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

四、redis主从复制部署

1、环境规划

服务器规划

master节点：192.168.10.105

slave01节点：192.168.10.106

slave01节点：192.168.10.107

安装依赖：（所有节点全部执行）

bash 复制代码

yum install -y gcc gcc-c++ make
# 下载redis安装包
wget -p /opt http://download.redis.io/releases/redis-5.0.7.tar.gz

2、redis安装

关闭防火墙和关闭增强服务（所有节点执行）

bash 复制代码

systemctl stop firewalld
systemctl disable firewalld
setenforce 0

安装redis（所有节点执行）

bash 复制代码

cd /opt
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd redis-5.0.7
make && make install prefix=/usr/local/redis
cd utils/
./install_server.sh
# 一直回车，直到跳出选择路径，输入/usr/local/redis/bin/redis-server
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server
# 软链接省略，因为redis相关文件已经被安装到/usr/local/bin/
# ln -s /usr/local/redis/bin/* /usr/local/bin/

3、修改redis配置文件(master、slave)

master节点：

bash 复制代码

vim /etc/redis/6379.conf
#修改为 0.0.0.0 后，Redis 对外暴露，必须搭配 requirepass（设置连接密码），否则任何人都能访问 / 篡改数据，这是生产环境的必做操作。
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程（后台进程）
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
appendonly yes #700行，开启AOF持久化功能

/etc/init.d/redis_6379 restart

slave节点：

bash 复制代码

vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录 #288行，指定要同步的
# Master节点IP和端口
#将当前 Redis 实例设置为指定主节点的从节点（副本节点），实现数据的主从同步。
replicaof 192.168.10.22 6379
appendonly yes #700行，开启AOF持久化功能

/etc/init.d/redis_6379 restart

4、验证主从结果

4.1、master节点验证

在Master节点上看日志：

tail -f /var/log/redis_6379.log

在Master节点上验证从节点：

redis-cli info replication

主节点写入数据，查看从节点

4.2、slave节点验证

redis-cli -p 6379

info replication

五、哨兵模式部署（所有节点）

1、环境规划

1.1、服务器规划

master：192.168.10.105

slave01：192.168.10.106

slave02：192.168.10.107

1.2、系统配置

systemctl stop firewalld

systemctl disable firewalld

setenforce 0

2、修改redis哨兵模式配置文件

bash 复制代码

vim /opt/redis-5.0.7/sentinel.conf
# 修改
protected-mode no #17行，关闭保护模式
port 26379 #21行，Redis哨兵默认的监听端口
daemonize yes #26行，指定sentinel为后台启动
logfile "/var/log/sentinel.log" #36行，指定日志存放路径
dir "/var/lib/redis/6379" #65行，指定数据库存放路径
sentinel monitor mymaster 192.168.10.23 6379 2 #84行，修改 指定该哨兵节点监控
sentinel down-after-milliseconds mymaster 30000 #113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000 #146行，故障节点的最大超时时间为180000（180秒）

3、启动哨兵模式

bash 复制代码

先启master，再启slave 
cd /opt/redis-5.0.7/ 
redis-sentinel sentinel.conf &

查看哨兵信息

redis-cli -p 26379 info Sentinel

4、故障模拟

bash 复制代码

# 查看redis-server进程号
ps aux | grep redis
# 关闭主节点
kill -9 pid # 或在redis交互页面shuntdown

追踪master和slave日志

tail -f /var/log/sentinel.log

在master节点输入以下内容，查看master是否被切换：

redis-cli -p 26379 INFO Sentinel

总结

本文全面覆盖 Redis 持久化机制、主从复制架构及哨兵模式，从理论原理到部署实操层层递进，通过环境配置与故障模拟，为高可用部署提供可直接落地的实践指南。