# Redis 持久化

# RDB

RDB 全程 Redis Database Backup file (Redis 数据备份文件), 也被叫做 Redis 数据快照。简单来说就是把内存的所有数据都记录到磁盘中。当 Redis 实例故障重启后,从磁盘读取快照文件,恢复数据.

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

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

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

1
2
3
4
5
6
7
8
# 是否压缩, 建议不开启, 压缩也会消耗CPU, 磁盘不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb

# 文件保存的路径目录
dir ./

# RDB fork 原理

bgsave 开始时会 fork 主进程得到子进程,子进程共享主进程的内存数据。完成 fork 后读取内存数据并写入 RDB 文件

fork 采用的是 copy-on-write 技术

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

image-20230208164740434

RDB 的缺点 :

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

# AOF 持久化

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

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

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

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

1
2
3
4
5
# 表示没执行一次写命令, 立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区, 然后表示每隔1秒钟将缓冲区数据写到AOF文件, 是默认方案
# 写命令执行完先放入AOF缓冲区, 由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
配置项刷盘时机有点缺点
Always同步刷盘可靠性高,几乎不丢数据性能影响大
everysec每秒刷盘性能始终最多丢失 1 秒数据
no操作系统控制性能最好可靠性较差,可能丢失大量数据

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

image-20230208170713984

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

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

# RDB 和 AOF 对比

RDB 和 AOF 各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会结合两者来使用

RDBAOF
持久化方式定时对整个内存做快照记录每一次执行的命令
数据完整性不完整,两次备份之间会丢失相对完整,取决于刷盘策略
文件大小会有压缩,文件体积小记录命令,文件体积很大
宕机恢复速度很快
数据恢复优先级低,因为数据完整性不如 AOF高,因为数据完整性更高
系统资源占用高,大量 CPU 和内存消耗低,主要是磁盘 IO 资源,蛋 AOF 重写时会占用大量 CPU 和内存资源
使用场景可以容忍数分钟的数据丢失,追求更快的启动速度对数据安全性要求较高常见