Redis持久化原理及配置详解(RDB方式和AOF方式)

Redis的强大功能很大程度上是由于其将所有数据都存储在内存中。为了使Redis在重启后仍能保证数据不丢失,需要将数据从内存中以某种形式持久化到硬盘中。Redis支持两种持久化方式,一种是RDB方式,一种是AOF方式。可以单独使用其中一种或两种结合使用。(持久化即将数据保存到磁盘,机器宕机或者重启数据不丢失,存储到内存中的数据会丢失)

1.RDB方式持久化

1.1 RDB的概念

RDB方式是通过快照方式完成的,当符合一定条件时Redis会自动将内存中的所有数据进行快照并且存储到硬盘上。进行快照的条件在配置文件中指定,有2个参数构成:时间和改动键的个数,当在指定时间内被更改的键的个数大于指定数值时就会进行快照。RDB是Redis默认的持久化方式。

1.2 RDB的配置

在配置文件中已经预置了三个条件

save 900 1 # 15分钟内至少有一个键被更改
save 300 10 # 5分钟内至少有10个键被更改
save 60 10000 # 1分钟内至少有10000个键被更改

以上条件是或的关系

默认的rdb文件路径是当前目录,文件名是:dump.rdb,可以在配置文件中修改路径和文件名,分别是dir和dbfilename

dir ./ # rdb文件存储路径
dbfilename dump.rdb # rdb文件名

如果没有触发自动快照,需要对Redis执行手动快照操作,SAVE和BGSAVE都是执行手动快照,但是两者有区别:可以通过SAVE和BGSAVE命令来手动快照,两个命令的区别是前者是由主进程进行快照,会阻塞其他请求,后者是通过fork子进程进行快照

注意:由于Redis使用fork来复制一份当前进程,那么子进程就会占有和主进程一样的内存资源,比如说主进程8G内存,那么在备份的时候,必须保证有16G的内存,要不然会启用虚拟内存,性能非常的差。

1.3 RDB功能测试:



这里可能会带来疑惑,明明已经开启了RDB配置,为什么Redis宕机后,数据还是丢失了呢?原因是由于没达到RDB持久化触发条件,所以我们手动触发RBD后再测试,如下图所示:



1.4 RBD文件的压缩:

RDB文件是通过压缩的,可以通过配置rdbcompression参数来禁用压缩,Redis默认是开启压缩的

压缩：
优点：减少磁盘存储空间
缺点：消耗CPU资源
不压缩：
优点：不消耗CPU资源
缺点：占用磁盘空间多

2. AOF方式持久化

2.1 AOF的概念

Redis的AOF持久化策略是将发送到Redis服务端的每一条命令都记录下来,并且保存在硬盘的AOF文件中。可以通过参数appendonly来设置是否启用AOF。AOF文件的位置和RDB的位置相同,都是通过dir参数设置,默认的文件名是appendonly.aof,可以通过appendfilename参数修改。

2.2 优化AOF文件

可以使用BGREWRITEAOF命令来重写AOF文件。目的是去除数据的中间执行过程,保存最终数据命令即可。

2.3 重写策略的参数设置

auto-aof-rewrite-percentage 100

当前的AOF文件大小超过上一次重写的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF大小为依据。

auto-aof-rewrite-min-size 64mb

限制了允许重写的最小AOF文件,通常在AOF文件很小的时候即使其中有些冗余命令也可是可以忽略的。

2.4 文件同步策略

文件写入默认情况下会先写入到系统的缓存中,系统每30秒同步一次,才是真正的写入到磁盘,如果在这30秒服务器宕机那数据也会丢失的

Redis可以通过配置来修改同步策略:

# appendfsync always 每次都同步(最安全但是最慢)
appendfsync everysec 每秒同步(默认的同步策略)
# appendfsync no 不主动同步,由操作系统来决定(最快但是不安全)

2.5 AOF持久化方式测试



由于还没达到RDB的持久化触发条件 所以这里有数据肯定用的是AOF持久化方式 到此AOF持久化成功生效