Redis数据持久化AOF和RDB原理

Redis的缓存管理机制

首先Redis是一种基于Key-Value结构的内存数据库。

而Redis设计者为了避免Redis故障而导致数据丢失的一个问题，提供了RDB和AOF两种持久化机制。

定时删除 + 惰性删除 + 内存淘汰

RDB和AOF的共同点

RDB和AOF都是Redis中数据持久化的一个机制。

RDB

RDB是一种快照的方式。也就说会根据快照的一个触发条件把内存里的数据快照写入到磁盘里面。

快照的触发方式

RDB的快照的触发方式有很多，执行bgsave命令触发异步快照，执行save命令触发同步快照。

【补充】异步快照和同步快照的区别在于同步快照会阻塞客户端的执行指令。

根据redis.conf文件里面的配置，自动触发bgsave。

主从复制的时候会触发。

以二进制压缩文件形式保存

RDB（Redis Database）是一种持久化机制，用于将Redis内存中的数据以二进制压缩文件的格式保存到磁盘文件中。

RDB持久化机制通过将当前内存中的数据生成快照并保存到磁盘文件中来实现数据的持久化。当执行保存操作时，Redis会将数据集的状态进行快照，并将其转换为二进制格式，然后将该快照保存到一个文件中。这个文件通常以.rdb作为后缀名。

遍历一遍，把他们全部写入文件中。为了节约空间，Redis定义了一个二进制的格式。

为了节约空间，Redis定义了二进制的格式，把数据一条一条码在一起，生成了一个rdb文件。但是Redis的数据量比较大，要是全部备份一次得花不少时间，所以不能太频繁地去做这件事。

如果一直没有写入操作，都是读取操作，那么redis也不用重复备份浪费时间。

Redis提供一个配置参数，既可以支持周期性备份，也可以避免做无用功。就像这样，多个条件可以组合使用。

后来，Redis创建一个子进程去做这件事。

缺点

RDB是快照，所以时间间隔就会有一个配置，在配置过程中，可能会存在数据丢失的一个问题。

相比之下，AOF是指令追加的方式，所以安全性比RDB更好一些。

AOF

AOF是一种指令追加的方式。它是一种近乎实时的方式。把Redis Server执行的事务命令进行追加存储。

简单来说，就是客户在执行一个数据变更的操作，Redis就会把这样的一个命令，追加到aof缓冲区。

然后再把缓冲区的数据写入到磁盘的aof文件里面。

至于最终什么时候真正把数据持久化到磁盘的aof文件里面，是根据磁盘的输盘策略来决定的。

将之前的写入命令都记录下来，专门写入了一个文件，并给这种持久化方式也取了一个名字AOF，AOF是Append Only File的简称。

AOF之所以称为“Append Only File”（追加写文件），是因为它的工作原理就是将新的写操作追加到现有文件的末尾，而不是修改已有的文件内容。

为避免每执行一条语句就记录导致的性能低下，Redis准备了一个缓冲区，然后把要记录的命令先临时保存在这里。然后再择机写入文件。

这个临时缓冲区叫做aof_buf。

缺点

因为AOF这种指令追加一个方式，会造成AOF文件过大，带来明显的IO性能问题。

随着时间的推移，备份文件越来越大。不仅非常占硬盘空间，复制移动、加载分析都非常的麻烦耗时。

因此Redis尝试将文件压缩一下，这个过程被称为AOF重写。最初，Redis打算去分析原来的AOF文件，然后将其中的冗余指令去掉来给AOF文件瘦瘦身。但因工作量大放弃，分析起来也比较麻烦。

也就是说当AOF文件大小达到某一个阈值的时候，就会把这个文件里面的相同的指令进行压缩。

指令合并

许多中间状态都没有用，采用将最终状态的方式记录下来即可。比如这三条指令可以合并成一条搞定。

这种方式还是很耗时间的。因此决定和rdb方式一样fork出一个子进程来做这件事情。

AOF重写数据不一致的问题

这样做之后子进程在重写期间，Redis如果修改了数据，就会出现和重写的内容不一致的情况。

因此Redis又准备了一个缓冲区aof重写缓冲区，从创建重写子进程开始的那一刻起，Redis将后面来的命令复制并写到这个重写缓冲区中。等到子进程重写文件结束之后，Redis再将这个缓冲区中的命令写入到新的aof文件中。最后再重命名新的文件，替换掉原来那个臃肿不堪的大文件。

具体对比

RDB是隔一段时间触发持久化，因此数据安全性低，AOF可以做到实时持久化，数据安全性较高。

RDB文件默队采用压缩的方式持久比，ADF存谐的是执行指令, 所以RDB在数据恢复的时候性址能比AOF要好。

参考资料：

1. 【趣话Redis第二弹】Redis数据持久化AOF和RDB原理一次搞懂！
2. 【Java面试】一个工作了5年的粉丝私信我，最近面试碰到很多Redis相关面试题