redis持久化总结

前言

本章对redis持久化相关内容进行一下总结。

持久化方案

1. RDB：Redis DataBase redis数据库，会按指定的时间间隔将数据生成快照文件存储在硬盘等介质中
2. AOF：Append Only File 仅附加文件，记录服务器接受的写指令，可以在服务器重启时执行这些命令用以恢复数据。
3. 无持久化
4. 混合持久化：仅4.0版本后支持

RDB

执行方式

redis会fork一个子进程按照时间间隔来进行持久化操作，主进程不受影响，所以可以保证redis本身
的性能。

优点

1. RDB可以按照时间间隔备份不同时间点的数据，可以更灵活的选择数据还原的版本
2. 其执行方式决定了他可以更好的保证redis本身的高性能
3. 相比AOF，在恢复数据时可以在保证速度的前提下恢复大规模的数据

缺点

1. RDB是按照时间间隔生成快照文件的，所以其必然会存在数据丢失的情况，无法保证数据的完整性
2. RDB的fork操作可能会阻塞主进程

AOF

执行方式

在开启AOF后，redis先将写命令放入缓存区，然后按照配置的策略将写命令追加到AOF文件中。
redis提供了不同的AOF策略：
1. 无fsync
2. 每秒fsync(默认)
3. 每个查询fsync
fsync即将命令从缓存追加到文件的操作

相比于RDB，AOF不可避免的问题是其文件会因为追加的命令越来越大，所以AOF提供了重写的操作
以控制文件大小。
其操作步骤如下：
1. fork一个子进程创建新的文件，然后将旧文件的命令进行分析压缩存入新文件，会剔除或者合
   并一些命令信息以减小文件大小
2. 在1执行的过程中，主进程依然会将命令存入缓存区及追加到旧文件中，以保证数据的完整
3. 待新文件处理完毕后，用新文件替代旧文件，然后将缓存区的命令追加到新文件中

优点

1. 相比RDB，AOF最明显的优点就是能保证数据的完整，不会丢失
2. 如果遇到磁盘已满或其他原因导致文件写入数据不完整，redis也提供了redis-check-aof修复
3. AOF文件作为一个日志文件可以很方便的导出

缺点

1. AOF文件通常会大于RDB的文件
2. 恢复数据时的加载速度也会慢于RDB

混合模式

混合持久化是4.0版本后出现的新的持久化方式。其结合RDB和AOF，生成前半部分是RDB后半部分是AOF
的文件。结合了二者优点，保证加载速度的前提下，兼容了增量数据的持久化。

执行方式

混合模式的执行方式与AOF大致相同，不同的是会先将全量副本以RDB形式写入aof文件
具体过程如下：
1. fork一个子进程
2. 将全量副本数据以RDB格式写入aof文件
3. 将缓冲区的命令一次写入aof文件中
4. 写入完成后通知主进程，覆盖旧文件

此时，新的aof文件前半部分是RDB格式的数据副本，后半部分是增量的命令。在恢复数据时，兼顾了
两者的优点。既能保证恢复的速度(RDB的优势)，也能避免数据的丢失(AOF的优点)。
其唯一的缺点或许是只能在4.0版本后使用。