redis——持久化之RDB、AOF

 

一  概述

目前持久化的方式有两种：快照；写日志

快照是把数据备份；写日志则是把操作过程记录下来，当我们需要恢复数据时，我们就把当时的操作重新执行一遍

AOF就是把过期的，没有用的，以及可以优化的命令进行化简，化简成一个很小的AOF文件。

1、redis也提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

2、RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；

3、AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

4、其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

5、如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。
 

 

 

二  RDB

 

先来看看什么是RDB

我们的RDB其实是通过一条命令将redis中的数据完整的生成一个快照，保存到硬盘中，也就是一个RDB文件

RDB的触发机制有三种：

1. save（同步）
2. bgsave（异步）
3. 自动

 

2.1   save

我们先来看save，save是同步的，所以当save的数据量较大时，会造成阻塞，

save会生成一个新的RDB文件，如果存在老的RDB本间，则会将新的RDB替换老的RDB文件。save的时间复杂度是O（n）

 

2.2  bgsave

bgsave不会像save一样去同步的执行RDB，它使用了linux的一个fork()函数，生成了主进程的一个子进程，让这个子进程去完成RDB的生成，但我们的RDB生成后，它会告诉我们主进程RDB生成成功了

bgsave的文件策略和复杂度和save是一样的

 

2.3 自动

我们去redis的配置文件中可以让redis自动持久化，redis的默认配置是

即如果90秒内有1条改动，则自动持久化；即如果300秒内有10条改动，则自动持久化；即如果60秒内有10000条改动，则自动持久化；

 

save与bgsave的比较

 

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。
 

 

 

三  AOF

 

 

 

3.1  AOF运行原理

 

3.2  AOF的三种策略

redis在执行写命令时，是先把数据写到硬盘的缓存区中，缓存区再根据对应的数据来写入硬盘中。

AOF一共有三种策略：always、everysec、no

三种策略的优缺点如下：

 

3.3  AOF重写

AOF重写就是对没有用的，重复的，可以优化的命令进行化简，化简成一个很小的AOF文件，这样可以减少磁盘的占用量，加速恢复速度。

AOF重现的实现方式有两种：

1. bgrewriteaof命令
2. AOF重写配置

我们来看下bgrewriteaof命令的执行过程

再来看看AOF重写配置

AOF的一些配置名和统计名

 

当同时满足下面条件时，则自动触发：

无论是使用bgrewriteaof命令或者使用自动配置，本质都会执行bgrewriteaof

 

 

 

四  RDB与AOF的对比