一、前言
前面学习了Redis的相关的十大数据类型以及用SpringBoot集成我们的Redis的工具代码的书写。从这篇文章开始，就会从Redis相关的一些理论（也是面试和工作的热点知识）如：Redis的持久化、Redis的订阅发布模型、Redis集群环境搭建、哨兵模式等等方面介绍Redis相关的进阶知识。希望对各位小伙伴能有所帮助。
二、Redis的持久化
1、为什么会有Redis的持久化
首先Redis是我们的缓存，是一种内存数据库，如果我们存储数据的时候，不将数据库状态储存到磁盘中，那么服务器一旦宕机、进程出现错误。服务器中的数据也会随之消失。所以为Redis提供持久化的功能是必不可少的！
2、Redis的持久化是什么
官网原话：
上面是官方对Redis持久化做出的解释，我们不难看出Redis的持久化就是将数据写入磁盘。而其中的关键操作其实是RDB与AOF。接下来会其详细展开介绍。
3、RDB
1、什么是RDB
Redis Database用官网的话说就是：在指定的时间间隔内将内存中数据集快照（Snapshot 像照相机那样咔嚓一下）写入磁盘，如果要恢复数据集则将快照文件读取到内存中。
工作流程：redis中会有一个父进程，正常的处理client发出的各种请求，此时如果要触发RDB生成RDB文件，则可以通过配置文件修改触发的操作我们称为自动触发、或则通过save和bgsave指令来手动触发来实现数据备份。此时父进程就会产生（fork）一个子进程来实现持久化，会先将数据写入一个临时文件中,待持久化结束后，再用这个临时文件代替上次持久化好的文件（rdb保存的文件就是一个dump.rdb文件）。整个过程主进程不进行 任何IO操作，确保了极高的性能。
2、RDB的触发
①RDB的自动触发
首先我们找到我们Redis下载的文件目录，我们找到以.conf结束的文件：
打开这个文件找到我们的快照Snapshot
正如Redis的配置文件所示 save <seconds> <changes>，当我们的时间间隔大于等于设置的seconds，修改次数大于等于changes时，Redis会自动触发RDB,生成对应的dump.rdb文件。
②RDB的手动触发
既然有自动触发，为什么需要手动触发呢。因为自动触发是规定操作内生成dump.rdb文件，但是如果有非常重要的数据需要及时存储，但是又不满足自动触发的需求。这时Redis官方，就为我们提供了save和bgsave两种手动触发的操作来 生成RDB文件。
a.save指令
用户可以通过执行SAVE命令，要求Redis服务器以同步方式创建出一个记录了服务器当前所有数据库数据的RDB文件。而且再持久化完成save指令的整个期间内，Redis都不能处理 其他的命令。SAVE命令是一个无参数命令，它在创建RDB文件成功时将返回OK作为结果。（注：线上禁止使用，不推荐）
b.bgsave
Redis会在后台异步进行拍照操作，不阻塞快照同时还可以响应客户端的请求，该持久化化会fork一个子进程，由子进程复制持久化的过程（父进程与子进程各做各的，会不干扰）。
③总结rdb文件的触发
1：通过我们的各种触发操作，会自动触发rdb规则；
2：除了以上，执行flushdb/flushall命令，也会触发rdb规则（为了保证数据的完整性,但是文件里面是空白的）；
3：退出redis，也会产生rdb文件。
4：主从复制时，主节点自动触发。
3、RDB的恢复
从以下方面恢复数据
①：只需将rdb文件放在我们Redis的启动目录下，redis启动时候会自动检查dump.rdb文件恢复其数据；
②：物理恢复，一定服务和备份分机隔离。（PS:不可以把备份dump.rdb文件和产生redis的服务器放在同一台机器，必须分开存储，以防生产机物理损坏后备份文件也挂了）
4、AOF
1、什么是AOF
Append Only File用通俗的话来讲：以日志的形式来记录每个写操作，将Redis执行的所以写操作指令记录下来（读操作不记录）。当重启Redis的时候会将新的持久化的日志文件中的数据恢复。
Redis中AOF的操作流程：
①：Client作为命令的操作者，会在redis中不断书写各种指令命令；
②：Redis并不会直接将这些指令命令直接写入AOF文件，而是先写在一个临时的AOF文件中（其实是一个缓冲区）。当这个临时文件的数量足够多时，再写入磁盘，避免了频繁的IO操作；
③：AOF的临时文件会根据三种写回策略（后面解释）将命令写入磁盘上的AOF文件中；
④：当AOF文件中的内容越来越多时，会执行AOF重写，起到AOF文件压缩的目的。
⑤：当Redis重启的时候会将AOF中的数据重新载入。
2、AOF中的常见配置指令
我们像RDB一样，找到AOF的配置文件，介绍相关指令：
1：appendonly no
默认不开启，我们需要手动进行配置，将"no"->"yes"
2：appendfilename "appendonly.aof"
表示修改的生成的aof文件的名称
3：三种回写策略机制
appendfsync always：同步回写，优：可靠性高，数据基本不丢失；缺：是一个极端，每个命令都要写到磁盘，性能影响大。
appendfsync everysec：每秒回写，优：性能适中；缺：宕机时，丢失一秒类数据。（Redis默认）
appendfsync no：OS控制的回写，优：新能好；缺：也是一个极端，宕机时，丢失数据数据较多。
4：AOF文件重写规则
首先aof默认文件无限追加，这样文件就会越来越大。
同时满足以下的关系，才会触发AOF的重写：
auto-aof-rewrite-percentage 100：根据上次重写后的aof大小，判断当前aof是不是增长了一倍
auto-aof-rewrite-min-size 64mb：如果aof文件大于64M,fork一个子进程来将我们文件进行重写
三、RDB与AOF的各自优缺点
1、RDB
优：
①：适合大规模的数据恢复
②：可以按照业务定时备份
③：对数据完整性和一致性要求不高
④：RDB文件在内存中加载速度比AOF快的多
缺：
①：在一定时间内做一次备份，如果redis出现宕机的话，就会丢失从当前开始的最近一次快照期间的数据
②：内存数据的全量同步，数据量太大，会大量使用IO,影响服务器性能
③：fork子进程的时候，会占用一定空间，需要考虑内存空间的问题
2、AOF
优：
①更好的保护数据不丢失、性能高、可做紧急恢复
缺：
①：在相同数据集下，aof文件要远大于rdb文件，恢复速度慢
②：aof的效率慢于rdb,所以redis默认的是使用rdb持久化
四、RDB和AOF的混合使用
1、谁的优先级大
我们知道Redis默认使用的是RDB，那么如果将aof与 rdb同时开启，是不是rdb的优先级就更大，先加载RDB文件呢？我们先来看个流程图:
从该图中我们可以看出，如果有aof文件，则先加载aof文件；若没有aof文件而开启了rdb则先加载rdb文件，如果两个都没开启，则该怎么执行就怎么执行。
2、开启RDB与AOF的混合模式
①：开启混合方式
aof-use-rdb-preamble yes（默认是yes）
②：开启结果
PS:前提是开启AOF。
RDB做全量的持久化，AOF做增量的持久化：即先使用RDB进行快照的储存，然后使用AOF持久化做所有写的操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。
总的来说最后生成的也是aof文件，但是该文件一部分包含了RDB格式，一部分包含了AOF格式。
如下所示：
五、总结
最后做一个总结，首先博主的这篇博客的记录是学习了b站上up主【狂神说JAVA】、【尚硅谷】的redis学习视频后写的。然后这篇博客也是在以前Redis版本上的基础上结合最新的版本完成的。当然博主自己写的这篇博客也是让我自己对Redis的持久化功能有了更进一步的认识，我个人觉得这篇博客对一些常见的关于Redis的持久化的面试题的回答是涉及的足够的。如果对正在阅读的小伙伴有帮助，不要忘记点赞👍哦。
