前言
redis 持久化支持两种方式 rdb 与 aof，文章记录两者的执行过程与配置。
一、rdb
rdb 持久化是把当前进程数据生成快照保存到硬盘的过程，触发 rdb 持久化过程分为手动触发和自动触发。
1. save 命令
会堵塞当前 redis 服务器，直到 rdb 结束为止，对数据量较大或者内存较大的实例，会堵塞较长时间，生产环境不建议使用。如果手动执行 save 命令，redis 会记录下方日志。
127.0.0.1:6379> save
ok
* db saved on disk
2. bgsave 命令
redis 进程执行 fork 操作创建子进程，rdb 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。如果手动执行 bgsave 命令，redis 会记录下方日志。
* background saving started by pid 90338
* db saved on disk
* rdb: 0 mb of memory used by copy-on-write
* background saving terminated with success
bgsave 对 save 堵塞进行优化，redis 内部涉及 rdb 操作都是由 bgsave 完成。
3. 内部触发 rdb 场景
-
使用 save 相关配置，如
save m n表示 m 秒内数据集存在 n 次修改时，触发一次 rdb； - 从节点执行全量复制操作，主节点自动执行 bgsave 生成 rdb 文件发送给从节点；
- 执行 debug relad 重新加载 redis 时，也会触发生产 rdb；
- 默认情况下，执行 shutdown 关闭 redis 时，如果没有开启 aof 持久化功能，则会触发 rdb。
4. rdb 参数配置
通过设置 dir 可以配置 rdb 保存位置 dbfilename 可以设置文件名。
config set dir /opt/redis-5.0.12/backup
config set dbfilename myback.rdb
redis 默认采用 lzf 算法对生成的rdb文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过 rdbcompression 参数配置。
config set rdbcompression{yes|no}
压缩 rdb 虽然会消耗 cpu 但是可以大幅度减少文件体积，方便存储或通过网络发送给从节点。
5. rdb 缺点
rdb 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。
rdb文件使用特定二进制格式保存，redis 版本演进过程中有多个格式的 rdb 版本，存在老版本 redis 服务无法兼容新版 rdb 格式的问题。
二、aof
aof（appendonlyfile）持久化：以独立日志的方式记录每次写命令，重启时再重新执行 aof 文件中的命令达到恢复数据的目的。aof 的主要作用是解决了数据持久化的实时性，目前已经是 redis 持久化的主流方式。
1. 参数配置
|
1
2
3
4
5
6
|
# 配置开启 aof
config set appendonly yes
# 配置文件名，默认 appendonly.aof
config set appendfilename xxx.aof
# 存储位置配置，与 rdb 一样
config set dir /opt/redis-5.0.12/backup
|
2. aof 执行流程
所有的命令都会追加到 aof_buf（缓冲区）中；aof 缓冲区根据对应的策略向磁盘同步操作；随着 aof 文件越来越大，需要定期对 aof 重写，达到压缩目的；当 redis 服务器重启时，可以加载aof文件进行数据恢复。 3. 重写机制
手动触发：
bgrewriteaof
自动触发，根据下方两个参数设置自动触发机制：
auto-aof-rewrite-min-size
auto-aof-rewrite-percentage
到此这篇关于redis 持久化 rdb 与 aof的文章就介绍到这了,更多相关redis 持久化 rdb 与 aof内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://blog.csdn.net/qq_42768234/article/details/121119225