1.什么是redis持久化？
redis是基于内存的数据库，存在断电数据丢失的情况。为了防止其数据断电丢失，就需要将数据存入硬盘中，这样当redis服务重启时，就会将硬盘中的数据恢复到内存中。Redis持久化的意义就是为了保证突然宕机，内存数据不会全部丢失。redis有两种持久化机制：RDB和AOF
2.redis持久化机制
2.1 RDB(Redis 数据库)
2.1.1 RDB是什么？
RDB是在指定的时间间隔内将内存中的数据集快照写入磁盘。保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中
2.1.2 PDB的配置文件
①Redis6.0.16以下
②Redis6.2以及Redis7
2.1.3 RDB触发机制
2.1.3.1 自动触发
（1）redis7版本，redis.conf里配置触发时间
（2）修改案例
（3）修改dump文件保存路径（默认配置是dir ./ 表示在哪启动server时候的时候，dump.rdb就在哪生成）
（4）修改dump文件名称
（5）如何恢复
①将备份文件(dump.rdb)移动到redis安装目录并重新启动服务即可
②执行flushall或者flushdb命令可以清空redis，也会产生dump.rdb文件，但里面是空的
③注意：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。
2.1.3.2 手动触发
（1）Redis提供了两个命令来生成RDB文件，分别是save和bgsave
（2）Save在主程序中执行会阻塞当前Redis服务器，直到持久化工作完成。在执行save命令期间，Redis不能处理其他命令，线上禁止使用
（3）BGSAVE是默认的方法，Redis会在后台异步进行快照操作，不阻塞快照的同时还可以响应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程
（4）Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就运行主进程同时可以修改数据
（5）fork是什么？
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。
（6）可以通过lastsave命令获取最后一次成功执行快照的时间
2.1.4 RDB的优点和缺点
（1）优点
①适合大规模的数据恢复
②按照业务定时备份
③对数据完整性和一致性要求不高
④RDB文件在内存中的加载速度要比AOF快得多
（2）缺点
①rdb是在一定间隔时间做一次备份，如果redis意外down掉的话，就会丢失当前最近一次快照期间的数据
②rdb是全量同步，如果数据量太大就会导致I/O阻塞，严重影响服务器性能
③rdb依赖于主进程的fork(通过复制父进程的内存，创建一个完全相同的子进程。这个子进程伴随着父进程一起运行，但有自己独立的内存空间)，在更大的数据集中，可能会导致服务请求的瞬时延迟
2.1.5 如何检查修复dump.rdb文件
2.1.6 哪些情况会触发RDB快照
（1）配置文件中默认的快照配置
（2）手动save/bgsave命令
（3）执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
（4）执行shutdown且没有设置开启AOF持久化
（5）主从复制时，主节点自动触发
2.1.7 如何禁用快照
（1）命令行模式：redis-cli config set save ""
（2）修改配置文件，将下面注释save ""打开
2.1.8 RDB优化配置项
（1）stop-writes-on-bgsave-error
（2）rdbcompression
（3）rdbchecksum
（4）rdb-del-sync-files
2.2 AOF
2.2.1 AOF是什么？
（1）以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
（2）默认情况下，redis是没有开启AOF(append only file)的。开启AOF功能需要设置配置：appendonly yes
（3）AOF保存的是appendonly.aof文件
2.2.2 AOF持久化工作流程
2.2.3 AOF缓冲区三种写回策略
2.2.4 AOF配置/启动/修复/恢复
2.2.4.1 配置
（1）配置文件默认写回策略为:每秒钟
（2）aof文件-保存路径
①redis6：AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
②redis7：dir + appenddirname
（3）aof文件-保存名称
①redis6：有且只有一个
②redis7,使用Multi Part AOF的设计
在appendonly.aof文件下采用Multi Part AOF的设计，分为基本(BASE)文件、增量(INCR)文件和清单(manifest)文件
2.2.4.2 启动
2.4.4.3 恢复
（1）正常恢复：重启redis然后重新加载，结果OK
（2）异常恢复：使用redis-check-aof --fix 进行恢复
2.2.5 AOF优点和缺点
（1）优点：更好的保护数据不丢失，可做紧急恢复
（2）缺点：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb;aof运行效率也要慢于rdb
2.2.6 AOF重写机制
（1）AOF重写机制是什么？
（2）AOF触发机制
①官网默认配置
②自动触发：满足配置文件中的选项后，Redis会记录上次重写时的AOF大小。默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
②手动触发：客户端向服务器发送bgrewriteaof命令
（3）重写原理
2.3 RDB-AOF混合持久化
（1）官网建议
（2）RDB-AOF混合持久化数据恢复顺序和加载流程
（3）开启RDB-AOF混合持久化
（4）开启RDB、AOF会影响Redis效率，可以使用纯缓存模式(同时关闭RDB+AOF)
