Redis:RDB和AOF两种持久化机制分析

RDB和AOF持久化区别分析

1、RDB：Redis Database
RDB模式是在单位时间内对数据库进行一次持久化，生成dump.rdb文件，该文件可以复制、编辑、移动；
例如：可以设置在每天之内，每间隔一个小时进行一次RDB文件存档，在一个月之内每天进行一次RDB快照存档；
存档操作有两种方式：SAVE和BGSAVE
下面是SAVE命令示例：如果至少1000个key被修改，则Redis会在每60秒进行一次自动存档，这种持久化策略成为快照

SAVE 60 1000

SAVE流程：
（1）触发快照操作
（2）父进程停止其他client的所有请求
（3）父进程开始将数据集（dataset）写入dump.rdb文件
（4）写入完成之后，父进程重新开启接收请求
BGSAVE流程：
（1）触发快照操作
（2）Redis调用forks函数复制父进程，生成子进程
（3）子进程开始将数据集（dataset）写入临时RDB文件
（4）子进程写入完成之后，将临时RDB文件重命名为dump.rdb文件并替换旧文件
缺点：
如果设置的执行间隔时间为5秒，Redis服务器在执行过程中出现问题（停电、数据熔断等）最多将会丢失5秒的数据；
2、AOF：Append Only File
AOF是在AOF文件后面追加Redis的操作日志，分为三种机制：完全没有fsync、每秒一次fsync、每条命令fsync（默认是每秒一次fsync）；当Redis文件过大时，redis会在后台自动开启rewrite，或者通过BGREWRITEAOF命令手动开启rewrite。

rewrite：就是在AOF文件过大，Redis对AOF文件进行分析，通过最简短的命令记录数据，重写完成之后重命名文件即可，下面的流程分析会详细讲解重写过程；

例如：开启每秒一次fsync，则会定时执行写入操作；
存档操作有两种方式：开机自启/命令触发
在redis.conf配置文件中添加：

appendonly yes

或者执行命令：将RDB方式切换为AOF，该方式只支持2.2版本及以后的

redis-cli config set appendonly yes
redis-cli config set save ""

注意：redis-cli config set save “”
命令是为了关闭RDB策略，如果需要同时开启两种持久化策略，第二条命令可以不执行；

两种方式的区别：
（1）redis.conf配置文件中添加appendonly yes信息，在redis开机的时候就启动了；
（2）通过命令设置的AOF持久化方式，在redis重启之后，将会把AOF关闭；
流程分析：
（1）触发重写操作
（2）Redis父进程触发forks函数，复制出子进程
（3）子进程创建出临时AOF文件，并将旧AOF文件数据分析，解析成最简短的命令
（4）父进程接收到的请求暂存到内存的缓冲区
（5）子进程完成数据重写之后，通知父进程
（6）父进程接收到子进程完成信息之后，将缓冲区的操作追加到新的AOF文件
（7）Redis通过原子操作重命名AOF文件，并开始使用新文件

AOF文件被截断怎么办？
写入AOF文件时服务器可能崩溃，或者写入时存储AOF文件的volume已满。发生这种情况时，AOF仍包含表示数据集给定时间点版本的一致数据（使用默认的AOF fsync策略，该数据可能已过期长达一秒钟），但是AOF中的最后一条命令可能会被截断。Redis的最新主要版本仍将能够加载AOF，只需丢弃文件中最后一个格式不正确的命令即可。
AOF损坏了怎么办？
如果AOF文件不仅被截断，而且在中间被无效字节序列损坏，则情况会更加复杂。
最好的办法是运行redis-check-aof实用程序，先不带–fix选项，然后了解问题，跳转到文件中的给定偏移，然后查看是否可以手动修复文件：AOF使用与Redis协议相同的格式，手动修复非常简单。也可以使用–fix参数为我们修复文件，但是从无效部分到文件末尾的所有AOF部分都可能会被丢弃，如果损坏恰好是在文件的初始部分，则会导致大量数据丢失。

最后：
RDB和AOF两种策略没有哪个更好，通常在实际应用中一块开启，共同使用；在启动时Redis会优先读取AOF文件，因为AOF记录的数据相对而言更完整；在数据恢复的时候通常使用RDB，因为RDB文件在备份之后更容易记录某个时间节点的数据，可以用来做容灾；

参考：redis官方文档