Redis - 持久化

AOF

Redis 每执行一条写命令，就把该命令以追加形式写入一个文件。再重启时，先去读取这个文件的命令，然后执行，就能恢复缓存数据。这种方式就是 AOF(Append Only File)

Redis 中 AOF 默认是不开启的，可以通过修改配置文件开启

如果每记录一条命令都要写回硬盘，那么会造成磁盘 IO 压力过大，进而阻塞进程

写回过程如下：

Redis 提供了 3 中写回硬盘的策略，控制上述第三步的过程

以上三种策略都无法完美解决主进程阻塞和数据丢失的问题

AOF 文件会随着写操作越来越多而变大，文件越大，带来的性能影响越大。因此提供了 AOF 重写机制，当 AOF 文件超过设定的阈值，就会触发 AOF 重写，来减小 AOF 文件大小

AOF 重写是指其会读取数据库所有键值对，然后将每一个键值对用一个命令记录到新的 AOF 文件。全部记录完之后，使用新的 AOF 文件替换旧的 AOF 文件

写入 AOF 文件的过程是在主进程完成了，但由于写入内容少，因此不太影响命令操作。

但在 AOF 重写时需要读取所有键值对并写入新文件，这个过程是很耗时的，因此不能放在主进程操作

RDB 是一个快照，记录的是某个瞬间 Redis 中的内存数据。因此在恢复数据时，RDB 的效率会比 AOF 高很多

Redis 有两个命令来生成 RDB 文件

RDB 的加载是在 Redis 启动时自动执行的

在配置文件中，可以通过配置来实现间隔时间自动执行 bgsave 命令

执行 bgsave 快照过程中，Redis 的主进程是可以继续处理请求的，因此是可以被修改的

bgsave 执行时，子进程与主进程共享内存数据，如果主进程要修改共享数据中的某一块数据，就会发生写时复制，这块数据的物理内存会被复制一份，然后主进程在这个数据副本进行修改操作。与此同时，子进程可以继续吧原来的数据写入 RDB 文件

在极端情况下，如果所有共享内存都被修改，则此时的内存占用是原来的两倍

RDB 比 AOF 数据恢复效率高，但是快照频率难以控制：

因此在 Redis 4.0 提出混合使用 AOF 日志和 RDB 快照

混合持久化工作在 AOF 日志重写的过程。在 AOF 重写时，会先将与主进程共享的内存数据以 RDB 方式写入 AOF 文件，然后主进程处理的操作命令会被记录在重写缓冲区，这些增量命令会以 AOF 方式写入 AOF 文件

因此使用了混合持久化之后，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据