关于redis的数据持久化问题

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发机制有手动和自动。

RDB是一个压缩的二进制文件按，是某一个时间点上的数据快照，适合备份、全量复制，比较适用于灾难恢复。redis加载RDB恢复数据远远快于AOF的方式。

RDB没有办法作到实时持久化（秒级），bgsave每次运行执行fork建立子进程，属于重量级操做，频繁执行成本高。流程以下：

• 手动触发

一、save：redis 127.0.0.1:6379> SAVE 

阻塞当前的redis服务器，直到RBD完成位置，对于内存较大的实例影响时间较长

二、bgsave：redis 127.0.0.1:6379> BGSAVE 

redis进程执行fork建立子进程，RDB持久化有子进程负责，完成后自动结束，阻塞只发生在fork阶段，时间极短

复制代码

• 自动触发

一、使用save的相关配置，如：“save m n ”，表示M秒内数据集存在N次修正，会自动触发

二、执行debug reload命令从新加载redis时，会触发

三、默认状况下执行shotdown时，若是没有开启AOF，会触发
复制代码

AOF

AOF以独立日志的方式记录每一次的些命令，重启时执行AOF文件，主要解决数据持久化的实时性。流程以下：

重写机制

随着命令不断写入AOF，文件会愈来愈大，redis引入AOF重写机制压缩文件。AOF文件重写是把redis进程内的数据转化为写命令同步到新的AOF文件的过程。

文件变小的缘由

• 进程内超时的数据再也不写入文件

• 旧的AOF文件内无效的命令，新生成的文件只保留最终写入数据的命令

• 多条命令合并为一个命令

数据从新加载

AOF和RDB均可以用于服务器重启时的数据恢复。其持久化文件加载流程以下：

文件的校验

• 当加载损坏的AOF文件时，会拒绝启动。

• 当加载错误格式的AOF文件时，会先备份，而后进行自动修复。

• 当机器忽然掉电致使文件不完整，redis会兼容这种状况（aof-load-truncated）