Redis 持久化操作

RDB(Redis DataBase Backup file)

Redis 数据备份文件,也被叫做 Redis 数据快照。简单来说就是把所有记录都记录到磁盘中。当 Redis 实例故障重启后,从磁盘读取快照文件,恢复数据。

快照文件称为 RDB 文件,默认保存在当前运行目录。
$ redis-cli
# 是由 Redis 主进程来执行 RDB,会阻塞所有命令
> save
# 开启子进程执行 RDB,会阻塞所有命令
> bgsave
Background saving started

Redis 持久化操作

默认 Redis 在停机时,会执行一次 RDB。

触发机制

Redis 内部有处罚 RDB 的机制,可以在 redis.conf 文件中找到,格式如下

# 900 秒内,如果至少有 1 个 key 被修改,则执行 bgsave,如果是 save "" 则表示禁用 RDB
save 900 1
save 300 10
save 60 10000

RDB 的其它配置也可以在 redis.conf 文件中设置

# 是否压缩,建议不开启,压缩会消耗 cpu
rdbcompression yes

# RDB 文件名称
dbfilename dump.rdb

# 文件保存路径
dir ./

RDB 实现原理

在操作系统中,每个进程是无法直接操作物理内存的,操作系统会给每个进程维护一个虚拟内存,在虚拟内存中维护了一个页表,对物理内存进行一个映射,基于页表的映射关系,这样进程就操作物理内存。
当进行 bgsave 时,会开始 fork 主进程得到子进程,子进程共享主进程的内存数据(在 fork 阶段,主进程是阻塞的)。完成 fork 后读取内存中的数据并写入 RDB 文件。fork 实质上是拷贝主进程的页表

Redis 持久化操作

但是在子进程进行 RDB 操作时,主进程还是可以接收请求,可能会导致读写之间的冲突,存在脏数据,对此,fork 采用的是 copy-on-write 技术

  • 当主进程执行读操作时,访问共享内存。
  • 当主进程执行写操作时,则会拷贝一份数据,执行写操作。

Redis 持久化操作

当然,在极端情况下,如果在子进程写 RDB 文件时,主进程不断有请求,对数据进行修改,如果对每条数据都执行了修改操作,那就会导致内存占用翻倍。

缺点

  • RDB 执行间隔时间长,两次 RDB 之间写入数据有丢失风险。
  • fork 子进程、压缩、写出 RDB 文件都比较耗时。

AOF(Append Only File)

AOF 全称 Append Only File(追加文件)。Redis 处理的每一个命令都会记录在 AOF 文件,可以看做是命令日志文件。

AOF 默认是关闭的,需要修改 redis.conf 配置文件来开启 AOF

# 是否开启 AOF 功能,默认是 no
appendonly yes
# AOF 文件的名称
appendfilename "appendonly.aof"

AOF 的命令记录频率也可以通过 redis.conf 来配置

# 表示每执行一次写命令,立即记录到 AOF 文件
apendfsync always
# 写命令执行完先放入 AOF 缓冲区,然后表示每隔 1 秒将缓冲区数据写到 AOF 文件,是默认方案
appendfsync everysec
# 写命令执行完先放入 AOF 缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

Redis 持久化操作

问题解决

由于 AOF 是记录每次 redis 的操作,会导致 aof 文件比较大,并且例如,在 set 操作之后,又有 del 操作,会导致效率问题。并且一个 key 可能会有多次 set 操作。

因为是记录命令, AOF文件会比RDB文件大的多。而且AOF会记录对同一-个key的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果。

例如

set num 123
set name hudu
set num 456

执行bgrewriteaof之后

# 是后台执行
BGREWRITEAOF
Backgroud append only file rewriting started

文件被压缩,并且命令被简化,可以理解为优化为

mset name hudu num 456

Redis 也会在触发阈值时自动去重写 AOF 文件。阈值也可以在 redis.conf 中配置

# AOF 文件比上次文件 增长超过多少百分比触发重写
auto-aof-rewrite-percentege 100
# AOF 文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb

对比

RDB AOF
持久化方式 定时对整个内存做快照 记录每一次执行的命令
数据完整性 不完整,两次备份之间会丢失 相对完整,取决于刷盘策略
文件大小 会有压缩,文件体积小 记录命令,文件体积很大
宕机恢复速度 很快
数据恢复优先级 低,因为数据完整性不如 AOF 高,因为数据完整性更高
系统资源占用 高,大量 cpu 和内存消耗 低,主要是磁盘 IO 资源,但 AOF 重写时会占用大量 cpu 和内存资源
使用场景 可以容忍数分钟的数据丢失,追求更快的启动速度 对数据安全性要求较高
本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!
未填写
文章
247
粉丝
18
喜欢
217
收藏
62
排名:731
访问:9753
私信
所有博文
社区赞助商