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的对比

发布了114 篇原创文章 · 获赞 199 · 访问量 20万+

猜你喜欢

转载自blog.csdn.net/qq_36582604/article/details/89388867