Redis 持久化机制详解：RDB 与 AOF 的实现原理
Redis 作为一个高性能的内存键值数据库，其数据主要存储在内存中。为了防止意外宕机或电力故障导致的数据丢失，Redis 提供了多种持久化（Persistence）策略，将内存状态保存到物理磁盘上。目前主流的实现方案主要分为 RDB 快照和 AOF 日志两种方式。
RDB 持久化：定时全量快照
RDB（Redis DataBase）持久化是指在指定的时间间隔内，将内存中当前时刻的数据集快照写入磁盘。它生成的 .rdb 文件是一个经过压缩的二进制文件，非常适合用于备份和灾难恢复。
触发场景
- 手动命令：执行
SAVE（阻塞式）或BGSAVE（非阻塞式）。 - 配置规则：基于 Redis 配置文件中的自动保存规则。
- 集群同步：主从架构下，从节点进行全量复制时，主节点会触发 RDB。
- 服务关闭：正常关闭 Redis 服务且未开启 AOF 时，会自动执行快照。
执行流程
RDB 的核心在于利用操作系统的 Copy-on-Write (COW) 机制：
- Redis 调用
fork()函数创建一个子进程。 - 父进程继续处理客户端的读写请求，而子进程开始将内存数据写入一个临时的 RDB 文件。
- 当子进程完成写入后，用这个临时文件替换原有的旧 RDB 文件。
配置示例
在 redis.conf 中，可以通过以下参数控制快照频率：
# 格式：save <秒数> <变更次数>
save 1200 1 # 1200秒内至少1个key变更
save 400 20 # 400秒内至少20个key变更
save 80 5000 # 80秒内至少5000个key变更
AOF 持久化：增量命令日志
AOF（Append-Only File）通过记录服务器执行的所有写命令来保存数据库状态。与 RDB 相比，AOF 提供了更高的数据安全性。
同步策略
Redis 提供了 appendfsync 参数来平衡写入性能与数据安全：
always：每个写命令都立即同步到磁盘，最安全但性能最低。everysec：每秒执行一次同步，性能与安全性的折中方案（默认）。no：由操作系统决定何时同步数据，性能最好但风险最高。
AOF 重写机制（BGREWRITEAOF）
随着运行时间的增长，AOF 文件会不断膨胀。为了解决这个问题，Redis 引入了重写机制，创建一个体积更小的 AOF 文件。
重写原理：重写并不读取旧的 AOF 文件，而是通过读取内存中的当前状态，生成能够构建该状态的最精简命令序列。例如，对同一个 Key 的 100 次自增操作，重写后会变成一条 SET 命令。
# AOF 重写配置
auto-aof-rewrite-percentage 100 # 当前文件比上次重写后增长了100%时触发
auto-aof-rewrite-min-size 128mb # 触发重写的最小文件体积
AOF 恢复逻辑
由于 AOF 记录的是原始命令，Redis 内部通过一个"伪客户端"（Fake Client）来执行文件中的命令。它会逐条读取命令并在内存中重新运行，直到恢复出完整的数据集。
RDB 与 AOF 的对比及选择策略
| 特性 | RDB (快照) | AOF (日志) |
|---|---|---|
| 数据安全性 | 较低，取决于最后一次快照时间 | 较高，通常仅丢失 1 秒数据 |
| 恢复速度 | 极快，直接加载二进制数据 | 较慢，需要逐条回放命令 |
| 性能影响 | fork 子进程开销，读写性能高 | fsync 磁盘 IO 开销 |
| 文件体积 | 较小，二进制压缩 | 较大，文本格式 |
在实际生产环境中，通常推荐同时开启两种持久化方式。Redis 在启动时会优先加载 AOF 文件，因为它的数据更完整；而 RDB 则作为长期备份和快速全量恢复的备选方案。
