聊聊Redis数据持久化备份

redis

缓存应用在服务中我们经常都会使用的,其中尤其是Redis,今天给大家聊聊Redis的数据持久化。

Redis持久化主要有两种方式,一种是RDB,一种是AOF。

其中RDB(Redis DataBase)持久化是以快照(snapshotting)方式进行,把存在某一时刻的所有数据写入硬盘过程。

AOF(append-only file)是以追加文件方式持久化,它以日志文件的方式记录每次的写命令,在服务重启再重新执行AOF文件命令来恢复数据。

这两种数据备份方式即可以同时使用,又可以单独使用。

RDB 快照持久化

首先我们看下RDB快照方式,这种持久化方式主要分为手动触发和被动触发。

手动触发分为SAVE和BGSAVE,由于SAVE会阻塞Redis服务,直到RDB过程完成,所以生产环境我们主要使用BGSAVE操作,执行BGSAVE之后,Redis进程会执行fork子进程,让子进程负责,直到自动结束。

被动触发是由于我们配置文件进行了save配置选项,如果用户设置了多个配置save配置选项那么任何一个条件满足就会触发BGSAVE。

我们可以看下下面的一段配置:

1
2
3
4
5
1. save 60 10000 # 60s有10000次写入(修改)被动触发BGSAVE
2. save 900 10 # 900s有10次就触发BGSAVE,保存到硬盘(两个满足一个就触发)
3. stop-writes-on-bgsave-error no # 创建快照失败是否继续写命令
4. rdbcompression yes # 是否进行压缩(默认压缩)
5. dbfilename dump.rdb # 生成文件名

其中save的配置需要我们进行合理评估,过频繁会浪费资源,过于稀少可能会有丢失大量数据隐患。

在这里我们需要知道通过快照持久化的方式来保存数据,如果服务发生故障,用户将会丢失最近一次生成快照之后更改的所有数据。

当然如果缓存数据小于或者只有几个GB时候,使用快照进行保存数据没有啥问题的。

AOF 追加持久化

由于RDB快照持久化适合小规模或丢失一部分数据也不会造成问题的应用,但是大多数场景里面,我们需要尽量保证数据完整性,所以这里我们有了AOF这种方式。

AOF持久化会将执行的命令写到AOF文件的末尾,来记录数据发生的变化,所以只需要将AOF的文件命令在Redis重新执行一遍就能恢复AOF文件的数据。

但是AOF文件会随着命令的不断增加,文件会越来越大,所以Redis有了重写机制,通过重写机制来压缩控制文件大小。

重写机制的原理就是合并多个命令,比如同样 inc 操作了100次,那么就可以合并为1次进行,或者之前添加了某个数据,后面又删除了就可以删除之前无效的命令等等。

AOF重写这种方式和RDB触发同样分为手动触发和被动触发。

手动触发方式:bgrewriteaof
被动触发方式:auto-aof-rewrite-percentage, auto-aof-rewrite-min-sieze

我们可以看下下面的配置:

1
2
3
4
5
appendonly no # 是否进行aof持久化
appendfsync everysec # 每秒同步一次,有always,no选项
no-appendfsync-on-rewrite no # aof重写期间是否同步
auto-aof-rewrite-percentage 100 # 当前文件是上一次大小的两倍的时候触发重写
auto-aof-rewrie-min-size 64mb # 文件最小体积触发重写

AOF重写和RDB快照方式一样,都会创建子进程,然后AOF子进程进行文件重写,所以快照持久化因为创建子进程导致性能和内存问题在AOF一样存在。

通过AOF的方式能相对更完善保留数据,让我们更为放心。

在这儿我们需要知道服务重启之后Redis默认加载流程,优先加载AOF文件,如果没有再考虑加载RDB文件。

最后

我们来简单总结一下RDB和AOF优缺点:

RDB优点:压缩二进制适合备份,加载恢复数据比AOF快
RDB缺点:没法做到实时持久化,频繁操作消耗资源

AOF优点:通过追加命令可以实时持久化
AOF缺点:加载恢复数据慢

有了这两种持久化方式,我们服务在重启或者宕机的时候就能更加完整保留数据,除了进行持久化操作外,我们也应该尽量把数据文件备份到不同服务器,避免在出现严重问题的时候不会丢失数据。

sitin wechat
扫一扫上面的二维码,订阅我的博客!