我要评论1.概述
在redis的使用中，持久化是一个重要的特性，它将内存中的数据保存到硬盘上，以防止数据丢失。
redis 提供了三种主要的持久化方式：aof（append only file）、rdb（redis database）以及混合持久化（rdb和aof）。
本文将详细介绍 aof 和 rdb 的区别及配置方式，帮助读者更好地理解和选择合适的持久化方式。
2.rdb和aof
2.1 rdb
2.1.1 rdb概念
rdb 持久化方式是 redis 将当前内存中的数据快照（snapshot）保存到硬盘的过程。
这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。其实就是每隔一段时间，redis 会创建一个代表某一时刻的数据集的磁盘文件。
2.1.2 rdb工作原理（copy-on-write）
rdb 的生成过程依赖于操作系统的写时复制（cow）机制，这一机制确保了快照生成期间 redis 依然能正常处理读写请求，不会阻塞业务。
具体流程如下：
- 1.触发快照生成：当满足预设条件时（时间到、达到修改次数阈值），redis 主进程会fork 一个子进程（此时子进程与主进程共享同一块内存空间）；
- 2.子进程写入快照：子进程负责遍历内存中的所有数据，将其序列化后写入一个临时的.rdb 文件；
- 3.主进程正常服务：在子进程生成快照期间，主进程继续处理客户端的读写请求。若有数据被修改，操作系统会为该数据块创建一个副本，主进程修改副本数据，而子进程依然读取原始数据（避免快照被污染）；
- 4.替换旧快照：当子进程完成快照写入后，会用临时文件替换当前的.rdb 文件，至此一次 rdb 持久化完成。
2.1.3 rdb触发方式
1.自动触发：基于配置的"指定时间+修改次数"
在redis 的配置文件（redis.conf）中，通过save指令定义rdb的触发规则，格式为：
save <seconds> <changes> [<seconds> <changes> ...]
表示 “在 seconds 秒内，若数据修改次数达到 changes 次，则触发 rdb”。
默认配置如下：
# 3600秒(1小时)内修改1次、300秒内修改100次、60秒内修改10000次，满足任一条件即触发rdb save 3600 1 save 300 100 save 60 10000
2.手动触发：主动备份场景
手动触发主要通过save、bgsave指令实现：
- save命令：由主进程直接生成 rdb，期间会阻塞所有客户端请求（线上不推荐使用，会阻塞请求导致业务中断）；
- bgsave命令：主进程 fork 子进程生成 rdb，主进程本身不阻塞（线上手动触发的首选指令）
3.rdb核心配置文件
#指定 rdb 文件的名称，默认为dump.rdb dbfilename dump.rdb #指定 rdb 文件的保存路径，默认是 redis 的启动目录（建议改为绝对路径，如/var/redis/） dir ./ #是否对 rdb 文件进行压缩（默认开启，用 cpu 开销换取磁盘空间，关闭可提升快照速度） rdbcompression yes #是否对 rdb 文件进行校验（默认开启，通过 crc64 算法确保文件完整性，关闭可提升加载速度） rdbchecksum yes
4.rdb优缺点
优点：
- 恢复速度快： rdb 是二进制的全量快照，加载时无需解析复杂指令，仅需反序列化数据，适合大规模数据的快速恢复；
- 文件体积小： 压缩后的 rdb文件体积远小于 aof 文件，便于备份和传输；
- 对性能影响小： 子进程负责生成快照，主线程仅在fork子进程时短暂阻塞（阻塞时间与内存大小相关，通常毫秒级），对业务读写影响低。
缺点：
- 数据一致性低： rdb获取的是“某一时间点快照”，若在两次快照间隔期间 redis 宕机，则该时间段内修改的数据将全部丢失（例如：配置save 30 1000，则最多可能丢失30秒的数据）；
- 文件可读性性低： rdb 文件是一个二进制文件，并不是一个易于读取和理解的文本文件；
- 不适合实时备份： 存在丢失数据的可能，适用于对数据一致性要求不高的业务。
2.2 aof
2.2.1 aof概念
aof其实就是将每一个收到的写命令都通过write函数追加到文件中，当 redis 需要恢复数据时，只需执行 aof 文件中的命令就可以恢复到原来的状态。
这个文件有点像mysql的binlog日志文件，只不过binlog日志文件是二进制，redis的aof生成的文件是文本格式。
2.2.2 aof工作原理
1.命令追加
- 每当 redis 执行一条写命令并成功处理后，会将该命令按照 redis 协议格式追加到内存中的 “aof 缓冲区”（避免直接写入磁盘，降低io开销）。
- 2.文件刷盘aof 缓冲区中的命令需要定期写入磁盘，刷盘策略由appendfsync配置决定。
3.日志重写
- 随着运行时间延长，aof 文件会产生大量重复命令（如多次set同一个key）而变得异常庞大，占用大量磁盘空间，还会导致redis重启恢复时间边长。
- redis携带了 “日志重写” 机制，会生成一个包含 “当前内存数据最终状态” 的精简 aof 文件，替换旧的aof文件，能有效降低空间占用率、提升恢复效率。
例如：
- 若指定key的值经过多次set，最终是value3，aof文件中记录了set key value1、set key
- value2、set key value3三条命令，重写后只会保留set key value3一条命令。
2.2.3 aof配置
1.启用aof
# 启用aof（默认no） appendonly yes # aof文件名称，默认appendonly.aof appendfilename "appendonly.aof" # aof文件保存路径，与rdb一致 dir ./
2.刷盘策略
appendfsync定义了 aof 缓冲区的命令何时写入磁盘，有三种可选值：
| 值 | 解释 |
|---|---|
| always | 每执行一条写命令，立即将缓冲区内容写入到磁盘，数据安全性高，io频繁 |
| everysec | 每秒将缓冲区内容写入磁盘一次，数据安全性一般，性能适中 |
| no | 由操作系统决定何时写入磁盘，默认30秒刷盘一次，数据安全性低，性能较高 |
3.日志重写规则
aof 重写同样支持自动触发和手动触发，自动触发通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置实现：
auto-aof-rewrite-percentage 100 # 当aof文件大小比上次重写后增大100%（即翻倍）时触发 auto-aof-rewrite-min-size 64mb # 当aof文件大小至少达到64mb时才触发（避免小文件频繁重写）
手动触发：执行bgrewriteaof命令，主进程 fork 子进程完成重写，不阻塞业务（和bgsave类似）。
4.aof优缺点
优点：
- 数据一致性高： 可通过appendfsync always实现 “数据零丢失”，或everysec实现 “最多丢失 1 秒数据”，满足高一致性需求；
- 日志可读性强： 由于aof 文件是一个易于读取和理解的文本文件，可以方便地进行数据恢复、备份和分析；
- 可靠性高： 记录了redis执行的所有写操作，可以提供更可靠的数据持久性，避免数据丢失。
缺点：
- 恢复速度慢： 恢复数据时需要执行大量的写命令，因此恢复速度相对较慢；
- 文件体积大： 即使经过重写，aof 文件体积通常仍大于 rdb 文件，占用更多磁盘空间；
- 性能开销较高： 每次写操作都需要追加到 aof 文件中，可能会导致磁盘 i/o 的负载增加。
2.3 rdb与aof对比
| rdb | aof | |
|---|---|---|
| 优点 | 文件体积小，恢复速度相对较快，对系统性能影响较小 | 可读性高，数据安全性高，支持实时恢复 |
| 缺点 | 数据安全性相对较低，可读性低，无法满足大规模、对数据备份要求高的场景 | 文件体积较大，恢复速度相对较慢，对系统性能有一定影响 |
| 适用场景 | 对数据安全性要求相对较低，希望快速地进行数据恢复 | 对数据安全性要求较高，而且可以接受稍慢一些的恢复速度 |
3.总结
1.rdb持久化方式能够在指定的时间间隔内对数据进行快照存储；
2.aof持久化方式记录每次对服务器写的操作，服务器重启时会重新执行这些命令来恢复原始的数据；
3.rdb和aof可同时开启，redis重启时会优先载入aof文件来恢复原始数据，因为通常情况下aof文件保存的数据集要比rdb文件保存的数据集要完整；
4.一般情况下，rdb文件只用作后备用途，建议只在slave机器上持久化rdb文件，并且只要15分钟备份一次就够了；
5.如果只做缓存，只希望数据在服务器运行的时候存在，其实不需要持久化操作。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论