Redis 持久化机制详解

Redis 作为一个高性能的内存数据库，天然存在内存数据易失的问题。为了在服务重启、故障或崩溃后能够恢复数据，Redis 提供了多种持久化机制，主要包括 RDB（快照持久化）、AOF（只追加文件持久化）以及 Redis 4.0 引入的混合持久化方式。本文将深入讲解这几种机制的原理、配置和各自的优缺点。

参考资料：
citeturn1search0（JavaGuide《Redis持久化机制详解》）
citeturn1search2（稀土掘金《深度好文：保姆级教程彻底搞懂Redis持久化》）

1. 为什么需要持久化

Redis 是基于内存的数据存储系统，其高速的读写性能正是依赖于内存存储的优势。但内存数据具有易失性，一旦服务器重启或意外宕机，所有存储在内存中的数据都将消失。因此，实现持久化的目的是将内存中的数据以某种方式存储到磁盘上，从而保证数据在异常情况或重启后能够恢复。持久化还便于数据备份、迁移以及主从数据同步。

2. Redis 持久化机制概述

Redis 主要提供三种持久化方案：

RDB 持久化
通过周期性生成内存数据快照（Snapshot）保存数据到磁盘上。适合备份、快速恢复，但存在一定数据丢失风险（最后一次快照之后的数据可能丢失）。
AOF 持久化
将 Redis 执行的每条写命令追加记录到日志文件中，重启时通过重放命令恢复数据。可以做到更高的数据安全性，但 AOF 文件通常较大，恢复速度较慢，同时文件不断增长需要周期性重写（Rewrite）。
混合持久化（RDB+AOF）
结合 RDB 快照与 AOF 日志的优点。Redis 定期生成快照，同时在两次快照之间用 AOF 记录所有写操作。重启时优先加载 AOF 数据，既能保证数据完整性，又能加速恢复过程。（Redis 4.0 及以上版本支持）

3. RDB 持久化

3.1 RDB 原理

RDB 持久化（Redis DataBase）通过在某个时间点对内存中全部数据进行快照，生成一个二进制文件（默认文件名为 dump.rdb）。当 Redis 重启时，会加载该文件恢复数据。

RDB 持久化主要通过两种方式触发：

手动触发
使用 SAVE（同步）或 BGSAVE（异步 fork 子进程进行快照）命令。
- SAVE 会阻塞整个 Redis 进程，适用于小规模数据测试；
- BGSAVE 利用 fork 创建子进程，在子进程中写入快照文件，不会长时间阻塞主线程。
自动触发
通过配置文件中的 save 参数实现。例如：
```
save 900 1
save 300 10
save 60 10000
```
表示在 900 秒内至少 1 次写操作、300 秒内至少 10 次写操作、60 秒内至少 10000 次写操作时自动触发快照。

citeturn1search5（CSDN《Redis教程(十)：持久化详解》）

3.2 RDB 优缺点

优点：

文件小、易于备份与传输： RDB 文件经过压缩后通常体积较小。
恢复速度快： 重启时直接加载整个快照，恢复速度高于 AOF 重放命令。
对运行性能影响小： BGSAVE 通过子进程生成快照，主进程仍可处理请求。

缺点：

数据丢失风险： 快照之间的数据修改无法持久化，可能丢失最后一次快照后的所有修改。
Fork 操作开销： 当数据量较大时，fork 可能会消耗大量 CPU 与内存资源，影响性能。

4. AOF 持久化

4.1 AOF 原理

AOF（Append Only File）持久化通过记录每一次写操作的命令来实现数据持久化。默认情况下，每条写操作命令都会被追加到 AOF 文件中。当 Redis 重启时，通过依次执行 AOF 文件中的命令来恢复数据。

AOF 持久化可以通过 appendonly yes 启用，默认文件名为 appendonly.aof。

4.2 同步策略

AOF 的写入和同步涉及三个步骤：

命令追加： 将每条写命令以协议格式追加到内存中的 AOF 缓冲区。
写入文件： 将缓冲区内容写入到操作系统内核的 Page Cache。
同步到磁盘： 根据配置使用 fsync 将数据从 Page Cache 同步到磁盘。

主要有三种同步策略（由 appendfsync 参数控制）：

always： 每执行一条命令后立即同步到磁盘，数据安全性最高，但性能较低。
everysec： 每秒同步一次，兼顾数据安全与性能（默认推荐设置）。
no： 由操作系统控制同步时机，性能最好，但风险较高。

citeturn1search9（LiZ的博客《Redis 中如何保证数据不丢失，持久化是如何进行的》）

4.3 AOF 重写机制

随着写操作不断追加，AOF 文件会不断增大。为了避免文件过大导致恢复速度慢、磁盘空间紧张，Redis 提供 AOF 重写机制：

重写过程： Redis fork 出一个子进程，在子进程中根据当前内存数据生成新的、精简的 AOF 文件。子进程重写期间，主进程继续追加新的写操作到一个重写缓冲区中。
切换文件： 重写完成后，将重写缓冲区的内容追加到新的 AOF 文件中，然后原子性地替换旧的 AOF 文件。

优缺点：

优点：

数据安全性高： 根据同步策略，可以保证数据基本不丢失（everysec 同步下最多丢失 1 秒数据）。
日志可读性好： AOF 文件记录的是可读的命令日志，便于分析和调试。

缺点：

文件体积大： 记录所有写操作，文件通常比 RDB 大。
恢复速度较慢： 重启时需要逐条执行命令恢复数据，速度比直接加载快照慢。

citeturn1search4（博客园《彻底搞懂Redis持久化机制，轻松应对工作面试》）

5. 混合持久化（RDB + AOF）

为同时兼顾数据恢复速度和数据安全性，Redis 4.0 引入了混合持久化方案：

原理： 定期生成 RDB 快照的同时，将两次快照之间的所有写操作通过 AOF 记录下来。重启时，先加载 RDB 快照，再重放 AOF 命令，实现数据恢复。
优势： 既利用 RDB 快照的快速恢复优势，又能用 AOF 保证较高的数据安全性，减少数据丢失。
适用场景： 对数据安全性要求极高且希望恢复速度较快的生产环境。

citeturn1search3（稀土掘金《全网最详细Redis教程之Redis持久化机制》）

6. 持久化方案选择及实践建议

选择哪种持久化方案，主要取决于业务对数据安全性、恢复速度和性能的要求：

仅使用 RDB： 如果允许分钟级别的数据丢失，且恢复速度要求较高，可选 RDB；优点是文件小、恢复快，但数据安全性较弱。
仅使用 AOF： 如果需要更高的数据安全性，且可以接受较慢的恢复速度，可选 AOF；推荐使用 appendfsync everysec 策略平衡性能和安全。
混合持久化： 对于既要求数据安全性又要求快速恢复的场景，建议同时启用 RDB 和 AOF，以混合持久化方式运行。

此外，在生产环境中，还需注意：