一、为什么需要持久化

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写回策略，手动触发还是可以的。