Redis持久化

 2024/09/19 

RDB持久化与AOF持久化

RDB持久化（快照持久化）
将当前数据保存到磁盘
AOF持久化（主流）
将每次执行的写命令保存到磁盘，mysql的iblogfile也是类似的原理
优点：实时性更好，意外丢失的数据更少
缺点：占用cpu，aof文件占用磁盘空间

RDB持久化

手动触发：通过save和bgsave进行保存
自动触发：通过配置redis.conf的save命令进行触发

save 900 1         # 900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10        # 300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000      # 60 秒内如果至少有 10000 个 key 的值变化，则保存

RDB文件
RDB文件是经过LZF压缩的二进制文件
其存储路径和文件名都在redis.conf
默认为redis目录下的dump.rdb
RDB文件的压缩是针对字符串进行的，字符串达到20字节才会进行
RDB文件在服务器启动时会自动加载，但优先级低于AOF，会优先加载AOF
载入RDB文件时处于阻塞状态
载入RDB文件时，会对RDB进行校验，如果文件损坏，就会报错启动失败
RDB持久化配置stop-writes-on-bgsave-error yes
当bgsave出现错误时，停止写入，避免数据大量丢失；如果已经对主机做了监控，可以设置为no
rdbcompression yes是否开启RDB文件压缩，建议开启
rdbchecksum yes是否开启校验，会降低性能，建议开启
dir dbfilename 文件存放目录与文件名

AOF持久化

默认开启RDB持久化，关闭AOF
appendonly yes开启AOF持久化

AOF流程

1.命令追加，将写命令追加到缓冲区aof_buf
2.文件写入、文件同步，根据不同同步策略将aof_buf中内容同步到硬盘
3.文件重写，定期重写AOF文件，整理（压缩）

AOF文件同步

AOF的同步文件策略由appendfsync参数控制，包含三种参数：

always 每次写入立即调用fsync，严重降低redis性能，非常安全
no 调用系统write操作，不进行fsync同步，同步由操作系统负责，周期30s，性能好但不安全，会丢数据
everysec 使用专门线程每秒进行fsync同步文件操作，折中了性能和安全性（推荐）

AOF文件重写原理

定期重写AOF文件，减小AOF文件的体积
需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作
1.过期的数据不再写入文件
2.无效的命令不再写入文件
3.多条命令可以合并为一个

AOF文件触发

分为手动触发和自动触发
手动触发：直接调用bgrewriteaof命令，原理和fork类似
自动触发：配置参数
auto-aof-rewrite-min-size 执行AOF重写时文件最小体积
auto-aof-rewrite-percentage 执行重写时，当前AOF大小与上次重写时AOF大小的比值，超出时会进行重写
↑同时满足才会触发

redis-cli查看参数
redis> config get auto-aof-rewrite-min-sizeredis> config get auto-aof-rewrite-percentage

3.2AOF重写缓冲区，重写时间写入的命令，会写入重写缓存区
5.2将重写缓冲区数据写入新AOF文件

AOF校验机制

当AOF开启时会优先载入AOF文件，并对AOF文件进行校验
1.如果AOF文件损坏，则会打印错误，启动失败
2.如果AOF文件尾部不完整，打印错误
参数aof-load-truncated 开启后(默认开启)，如果不完整，会输出警告但启动成功

AOF配置总结

appendonly no 是否开启AOF
appendfilename AOF文件名
dir 文件目录
appendfsync everysec fsync的持久化策略
no-appendfsync-on-rewrite no AOF重写期间是否禁止fsync；如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失AOF重写期间的数据；需要在负载和安全性之间进行平衡
auto-aof-rewrite-percentage 100 文件重写触发条件
auto-aof-rewrite-min-size 64mb  文件重写触发条件
aof-load-truncated yes          如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件

redis持久化方案选择

1.完全放弃安全性，如redis作为DB数据的cache，那无论是单机还是主从都可以不进行持久化
2.单机环境下，可以接受10分钟以上的数据丢失，选择RDB性能更好，如果只能接受秒级丢失，选择AOF
3.多数情况下，配置主从环境，从节点可以实现热备，也可以读写分离分担redis请求，以及master宕机后继续提供服务

综合使用AOF和RDB两种持久化机制
用AOF来保证数据不丢失，作为数据恢复的第一选择，用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

主从环境
master:完全关闭持久化
slave:只读不写
关闭RDB，开启AOF，定时对持久化文件进行备份
关闭AOF自动重写，通过定时任务在闲时调用bgrewrite

如果没有持久化存储
1.如果master和slave同时停止，即使设置了主从复制热备，数据也会全部丢失
2.如果master误重启，服务拉活，如果两个节点都没有持久化，就会导致slave也变空了。应当避免拉活与不持久化同时出现

原文作者：王盛

原文链接：https://akemi.zj.cn/2024/09/19/Redis-Persistence/

发表日期：September 19th 2024, 10:07:55 pm

更新日期：February 20th 2025, 6:37:27 pm