持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第11天，点击查看活动详情

假如Redis同时开了RDB和AOF会怎样？

优点：

全量备份（但是是启动时刻的快照）

存储的是数据，恢复时直接加载进内存即可，速度快

缺点：

因为是快照形式的持久化，所以在持久化过程中就算有外部请求改变了数据，快照也是不可见的；这样子，如果持久化时间较长，那可能掉电丢失的数据就比较多了

刚刚说了RDB是启动时刻的全量备份，它不能记录持久化过程中的数据，所以现在我们就来聊一聊另一种持久化方式——AOF持久化。

AOF持久化是一种增量备份的策略，它会将Redis中对数据操作的每一个命令记录到 appendonly.aof 文件中去（该文件记录的是命令）。

每执行一条操作数据的命令就将其追加在 appendonly.aof 文件中。

AOF的重写机制

AOF的重写机制其实就是对 appendonly.aof 文件中记录的命令执行以下操作：

合并重复的命令

对同一数据处理的命令，只保留最新的

可以看到AOF的重写实际上就是对 appendonly.aof 文件的一种瘦身。

因为 appendonly.aof 文件是不断地追加的，如果没有瘦身机制的话，该文件则可能会非常大。

优点：

以增量的形式持久化，掉电丢失的数据少

缺点

appendonly.aof 文件中记录的是命令，掉电恢复的时候，需要重新执行命令，速度相对于RDB来说较慢。

RDB恢复速度较快，AOF可以增量持久化，那可不可以将两者的优点整合在一起呢？

其实是可以的，我们可以两种持久化方式都开启（AOF默认是不开启的）

开启两种持久化方式之后，有以下需要注意的：

在redis4.0之前：

虽然是两种持久化方式都开启了，也就是说会产生 dump.rdb 和 appendonly.aof 两种文件，但是掉电恢复时，是只会使用 appendonly.aof 来恢复的！

也就是说 dump.rdb 记录了也没用

在Redis4.0之后，优化了以上的问题：

将RDB持久化的数据写进 appendonly.aof 文件，而不是 dump.rdb 文件；最后AOF持久化的命令就追加在 appendonly.aof 中RDB持久化的数据之后

也就是说，这种情况下， appendonly.aof 文件的前部分是 RDB的数据，后部分才是AOF的数据。

这样掉电恢复时，使用 appendonly.aof 文件来恢复；因为前面的数据是RDB记录的二进制形式的数据，所以直接加载进内存即可，而appendonly.aof 后面是少量的 AOF记录的命令，则需要重新执行。

这样就可以很好地整合了RDB和AOF的优势了！