Redis持久化：RDB和AOF

原创

Eulogy

发布于 2025-08-05 19:07:54

16200

代码可运行

文章被收录于专栏：笔记本笔记本

运行总次数：0

代码可运行

RDB和AOF

RDB

磁盘中会有一个.rdb文件来持久化redis内存中的数据。

我们可以自己配置生成.rdb文件的时机（save \<seconds> \<changes>代表距在seconds时间内，并且有changes次修改就开启持久化线程进行.rdb文件的生成），可以看成一个滑动窗口，在每个操作之后都会检查前seconds时间是否有超过changes次修改操作。每次生成.rdb文件之后都会重置“起始时间”和“修改次数”。

有 save命令 和 bgsave 命令，save命令会使用redis的 主线程 来生成.rdb文件，会阻塞redis的其它操作。而bgsave会fork一个 子线程 ，不会阻塞redis其它操作，由子线程来进行.rdb文件的快照式生成，生成的时候redis正常运行，redis只会允许一个子线程来进行.rdb文件，如果已有子线程在执行持久化操作的时候，条件又满足了，那么就会忽略这次的持久化操作。

redis在停机结束的时候，会执行一次 save 操作。

fork原理： 首先我们要知道进程是没办法直接操作物理内存的，而只能操作虚拟内存，然后通过页表映射到物理内存上去，主进程fork一个子进程来执行rdb文件生成操作就是把页表拷贝给子进程，子进程根据虚拟地址和页表就可以访问当跟主进程一样的物理内存了。

copy-on-write： 在生成.rdb文件的时候，所有数据都会被标上“read-only”。如果有写请求来了，那么主进程就会将被修改的数据复制一份，然后再进行修改，之后主进程对该份数据的操作就都会是在新复制了的数据上了。读时共享，写时复制。生成.rdb文件的子进程还是使用的read-only的数据。

AOF

AOF（append only file），追加文件的形式来记录每一个对redis的写操作命令，直接以命令的形式保存在aof文件里，类似于日志。aof默认是关闭了，需要在redis.conf中开启。

在 Redis 中，AOF（Append Only File） 的命令记录频率可以通过配置文件 redis.conf 中的参数： appendfsync

该参数控制 AOF 写入和 fsync 的频率，即多久将写入的命令同步到磁盘。你可以在 redis.conf 中找到如下配置项：

appendfsync always
appendfsync everysec
appendfsync no

配置项	含义
`appendfsync always`	每次写入 AOF 都执行 `fsync()`（最安全，性能最差）
`appendfsync everysec`	每秒执行一次 `fsync()`（默认选项，性能与数据安全的折中）
`appendfsync no`	不主动执行 `fsync()`，完全依赖操作系统的缓冲区刷新机制（性能最好，最不安全）

aof在内存中也对应有一个缓存，每条命令都会先保存到这个缓存中，然后在 appendfsync everysec 状态下，每秒都会将缓存里的命令持久化到aof文件中。

区别

RDB vs AOF 区别对比表

比较维度	RDB（快照）	AOF（追加日志）
触发方式	定时或手动触发（如 `save` 或 `bgsave`）	实时追加写命令（根据 `appendfsync` 策略）
保存内容	某一时刻的全量数据快照	所有写操作的命令日志
文件格式	`.rdb` 文件	`.aof` 文件
数据恢复速度	快（直接载入内存）	慢（逐条重放写命令）
数据安全性	丢失最后一次快照后的数据（可能几分钟）	最多丢失 1 秒内的数据（`everysec` 模式）
对性能影响	低（只在快照时影响性能）	高（每次写入都记录日志）
文件大小	较小	较大（可配置自动重写优化）
是否可读	二进制格式，不易读写	文本格式，可读可编辑
适用场景	对性能要求高、可容忍少量数据丢失（如缓存型系统）	对数据安全要求高，需最小化数据丢失（如计费系统、订单系统）
重写机制	无重写，只能新建快照	有自动或手动重写机制，压缩旧命令

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

redis

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

redis

登录后参与评论

0 条评论

热度