文章目录
- 前言
- 一、持久化
- 1、持久化介绍
- 2、rdb持久化
- 2.1、rdb快照
- 2.2、触发条件
- 2.3、bgsave流程原理
- 3、AOF持久化
- 3.1、aof介绍
- 3.2、开启AOF
- 二、主从复制
- 1、主从复制介绍
- 2、主从复制作用
- 3、主从复制流程
- 三、哨兵模式
- 1、哨兵模式介绍
- 2、哨兵模式原理
- 3、哨兵模式作用
- 4、故障转移机制
- 四、redis主从复制部署
- 1、环境规划
- 2、redis安装
- 3、修改redis配置文件(master、slave)
- 4、验证主从结果
- 4.1、master节点验证
- 4.2、slave节点验证
- 五、哨兵模式部署（所有节点）
- 1、环境规划
- 1.1、服务器规划
- 1.2、系统配置
- 2、修改redis哨兵模式配置文件
- 3、启动哨兵模式
- 4、故障模拟
- 总结
前言
本文围绕 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
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。
其他触发快照的场景：
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
# 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
安装依赖：（所有节点全部执行）
yum install -y gcc gcc-c++ make
# 下载redis安装包
wget -p /opt http://download.redis.io/releases/redis-5.0.7.tar.gz2、redis安装
关闭防火墙和关闭增强服务（所有节点执行）
systemctl stop firewalld
systemctl disable firewalld
setenforce 0安装redis（所有节点执行）
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节点：
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节点：
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哨兵模式配置文件
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、启动哨兵模式
先启master，再启slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &查看哨兵信息
redis-cli -p 26379 info Sentinel
4、故障模拟
# 查看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 持久化机制、主从复制架构及哨兵模式，从理论原理到部署实操层层递进，通过环境配置与故障模拟，为高可用部署提供可直接落地的实践指南。
