一、为什么需要持久化
redis本身运行时数据保存在内存中，如果不进行持久化，那么在redis出现非正常原因宕机或者关闭redis的进程或者关闭计算机后数据肯定被会操作系统从内存中清掉。当然，redis本身默认采用了一种持久化方式，即RDB （Redis DataBase），可以在redis的目录中找到dump.rdb文件，这就是使用RDB方式做持久化后生成的数据文件。
二、常见的两种持久化方式
一、RDB(Redis Database)快照
1、是什么：即redis数据库，rdb持久性以指定的时间间隔执行数据集的时间点快照。
2、作用：
在指定的时间间隔内将内存中的数据集快照写入磁盘。也就是Snapshot内存快照。等redis回复时再将硬盘快照文件直接读回到内存里。保存备份时执行的是全量快照，把内存中的所有数据都保存到dump.rdb文件
3、持久化触发类型：
自动触发：
手动触发：
Redis提供了两个命令来手动生成RDB文件
save：在主进程中执行会阻塞当前redis服务器，直到持久化工作完成，在执行save命令期间，redis不能处理其他命令，线上禁止使用。
bgsave：redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程。
注意：生产上只允许用bgsave，不允许用save
lastsave：获取最后一次成功执行快照的时间，获取到的是时间戳，在Linux中可以使用date -d @时间戳进行时间的转换
4、如何恢复
将备份文件移动到redis安装目录并启动服务即可。
注意：1、执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，没有任何意义。2、物理恢复，服务和备份分机隔离。以防止生产机物理损坏后备份文件也挂了。
5、优劣势
优点：官网
1、适合大规模数据恢复
2、按照业务定时备份
3、对数据完整性和一致性要求不高
4、RDB文件在内存中的加载速度要比AOF快得多
缺点：官网
1、在一定间隔时间做一次备份，如果redis意外宕机了，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失。
2、内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
3、RDB依赖于主进程的fork，在更大的数据集中，这可能导致服务请求的瞬间延迟。fork的时候内存数据被克隆了一份，大致两倍的膨胀，需要慎重考虑。
6、使用redis -check -rdb 对损坏的rdb文件进行修复
7、RDB的触发
1、配置文件中默认的快照配置，即多少时间内进行了多少次redis数据的操作触发rdb持久化机制
2、手动save/bgsave命令
3、执行flashall/flashdb命令也会产生dump.rdb文件，但里面是空的，无意义。
4、执行shutdown且没有设置开启aof持久化
5、主从复制时，主节点自动触发
8、禁用rdb
1、redis-cli config set save ""：动态的所有停止rdb保存规则
2、配置文件上禁用
二、AOF(Append Only File)
一、是什么
二、能干什么
主要是记录每次redis的除读取操作外的所有操作指令，AOF保存的是appendonly.aof文件
三、AOF持久化工作流程
四、AOF缓冲区三种写回策略
1、Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘。
2、everysec（默认写回策略）：每秒写回，每个写命令执行完，只是先把日志写到aof文件的内存缓冲区，每隔1秒把缓冲区中的内容写入到磁盘文件。
3、no：操作系统控制的写回。每个命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
五、redis7 Multi Part AOF 的设计
redis7之前AOF文件有且只有一个 ，redis7之后有三个文件：base基本文件、incr增量文件、manifest清单文件，且有一个配置目录用于和rdb区分
六、AOF异常文件修复
七、优劣势
优势：
劣势：
1、对于相同数据集的数据而言AOF文件要大于RDB文件，且恢复速度要慢于RDB
2、AOF运行效率慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同
八、AOF重写机制
1、是什么
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集
2、两种触发机制
自动触发：
手动触发： 直接发送bgrewriteaof命令
重写原理：
自Redis 7.0.0以来，当安排AOF重写时，Redis父进程会打开一个新的增量AOF文件以继续写入。子进程执行重写逻辑并生成新的基本AOF。Redis将使用一个临时清单文件来跟踪新生成的基本文件和增量文件。当它们准备好后，Redis将执行原子替换操作，使这个临时清单文件生效。为了避免在AOF重写重复失败和重试的情况下创建许多增量文件的问题，Redis引入了AOF重写限制机制，以确保失败的AOF重写以越来越慢的速度重试。
Redis会fork一个子进程，所以现在我们有了一个子进程和一个父进程。
子级开始在临时文件中写入新的基本AOF。
父级打开一个新的增量AOF文件以继续写入更新。如果重写失败，旧的基本文件和增量文件（如果有的话）加上这个新打开的增量文件代表了完整的更新数据集，所以我们是安全的。
当子级完成重写基本文件时，父级会得到一个信号，并使用新打开的增量文件和子级生成的基本文件来构建临时清单，并将其持久化。
利润现在Redis对清单文件进行原子交换，以便AOF重写的结果生效。Redis还会清理旧的基本文件和任何未使用的增量文件。
总结：
三、AOF+RDB混合使用
一、同时开启两种持久化方式
reds默认是开启RDB持久化，而不会开启AOF持久化方式，如果两者同时开启，redis优先加载AOF持久化。
二、redis加载顺序
当redis重启的时候会优先加载AOF文件来恢复原始的数据，因为通常情况下AOF文件保存的数据集要比RDB文件保存的数据集更完整。RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。由于RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着RDB作为一个兜底策略。
四、纯缓存模式
redis并不做持久化，只用做高速缓存，禁用持久化机制可以提高性能。
1、关闭RDB：save ""；禁用RDB自动触发模式，手动触发还是可以的
2、关闭AOF：appendonly no；禁用AOF写回策略，手动触发还是可以的。
