缓存应用在服务中我们经常都会使用的,其中尤其是 Redis,今天给大家聊聊 Redis 的数据持久化。
Redis 持久化主要有两种方式,一种是 RDB,一种是 AOF。
其中 RDB ( Redis DataBase )持久化是以快照( snapshotting )方式进行,把存在某一时刻的所有数据写入硬盘过程。
AOF ( append-only file )是以追加文件方式持久化,它以日志文件的方式记录每次的写命令,在服务重启再重新执行 AOF 文件命令来恢复数据。
这两种数据备份方式即可以同时使用,又可以单独使用。
首先我们看下 RDB 快照方式,这种持久化方式主要分为手动触发和被动触发。
手动触发分为 SAVE 和 BGSAVE,由于 SAVE 会阻塞 Redis 服务,直到 RDB 过程完成,所以生产环境我们主要使用 BGSAVE 操作
,执行 BGSAVE 之后,Redis 进程会执行 fork 子进程,让子进程负责,直到自动结束。
被动触发是由于我们配置文件进行了 save 配置选项,如果用户设置了多个配置 save 配置选项那么任何一个条件满足就会触发 BGSAVE。
我们可以看下下面的一段配置:
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 时候,使用快照进行保存数据没有啥问题的。
由于 RDB 快照持久化适合小规模或丢失一部分数据也不会造成问题的应用,但是大多数场景里面,我们需要尽量保证数据完整性,所以这里我们有了 AOF 这种方式。
AOF 持久化会将执行的命令写到 AOF 文件的末尾,来记录数据发生的变化,所以只需要将 AOF 的文件命令在 Redis 重新执行一遍就能恢复 AOF 文件的数据。
但是 AOF 文件会随着命令的不断增加,文件会越来越大,所以 Redis 有了重写机制,通过重写机制来压缩控制文件大小。
重写机制的原理就是合并多个命令,比如同样 inc 操作了 100 次,那么就可以合并为 1 次进行,或者之前添加了某个数据,后面又删除了就可以删除之前无效的命令等等。
AOF 重写这种方式和 RDB 触发同样分为手动触发和被动触发。
手动触发方式:bgrewriteaof 被动触发方式:auto-aof-rewrite-percentage, auto-aof-rewrite-min-sieze
我们可以看下下面的配置:
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 缺点:加载恢复数据慢
有了这两种持久化方式,我们服务在重启或者宕机的时候就能更加完整保留数据,除了进行持久化操作外,我们也应该尽量把数据文件备份到不同服务器,避免在出现严重问题的时候不会丢失数据。
1
YzSama 2018-10-18 23:56:24 +08:00 via iPad
rdb 适合定时备份。aof 适合实时备份。
|