前言

Redis虽然是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题Redis提供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失。

我们一共提供了以下几种方式进行持久化：

RDB
AOF
RDB+AOF混合持久化

一、RDB

RDB：以快照的形式，将redis中的数据保存成一个经过压缩二进制文件。它可以手动执行（save/bgsave命令），也可以再redis.conf中配置（save 60 1000行），定期执行。

1.save 和 bgsave对比

了解即可（只要记住，bgsave不阻塞，save阻塞命令。我们多用bgsave即可）

2.RDB的优点和缺点

2.1 优点

占用的内存空间比较小=》因为是压缩过的二进制文件
恢复的快=》二进制文件

2.2 缺点

数据安全性低=》快照是有周期的，并且我们不能频繁的快照效率低。因此我们容易丢数据

二、AOF

AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间
fsync到磁盘)。在AOF持久化的文件中，数据库会记录下所有变更数据库状态的命令（记录每一条修改redis数据的相关指令），除了指定数据库的select命令，其他的命令都是来自client的，这些命令会以追加(append)的形式保存到文件中。

1.AOF重写

AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件
如上面的介绍，就是当我们执行一些语句时，进行AOF重写时，会判断这些语句能不能合并，能的话就合并。避免浪费空间，并且提高恢复的速度。

2.AOF的优点和缺点

2.1 优点

数据安全性高，每条指令都会写到aof中

2.2 缺点

文件大=》指令太多
恢复慢=》指令多

3 RDB和AOF对比

三、AOF+RDB混合持久化

我们为了结合两个持久化的优点（AOF数据安全性高和RDB小并且快的优点）。redis4.0之后引入了混合持久化的方式

1 原理

首先我们要开启AOF，这种混合持久化，主要还是基于AOF的。
然后就是AOF重写的时候，将我们的写再aof文件中的指令，进行一次RDB快照的方式，将之前的在aof文件中的指令以二进制压缩的方式存在aof中
再者就是新进来的指令，依然是以指令的方式保存在aof文件中。等待下一次AOF重写才会再一次进行RDB快照。以此类推

2 如图

Redis数据备份策略（其实就是去备份我们的rdb/aof两个文件）：

写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48
小时的备份
每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
每次copy备份的时候，都把太旧的备份给删了
每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏

四、部署架构

1、主从架构

其实这都比较简单，相信做技术的各位大佬一看就懂了。搞几张大佬的图片看一下

内部原理如下

全量复制（用于第一次从节点连接上主节点的时候）
部分复制（用于使用期间从节点挂掉一小段时间）=》这里最重要的就是会有一个缓存区，这里不会放太多的数据，所以挂太久还是会使用全量复制

注：当我们使用一主多从的时候，可能会造成复制风暴【复制风暴就是：主节点向多个从节点写数据的情况】那这个时候我就引入了如下结构

2、哨兵架构

哨兵架构，是为了防止我们的主节点或者其他节点挂掉的时候，我们能监听到。

tinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过
sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis
主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)
重新推崇一个主节点的形式