2. Redis数据持久化机制总览

Redis 是内存数据库，数据默认只存在于内存中，一旦进程退出或机器断电，内存里的数据就会全部丢失。持久化机制要解决的核心问题就是：把内存中的数据集以某种形式落到磁盘，并在重启时重新装载回内存。Redis 提供了三种持久化形态——RDB、AOF 以及两者结合的混合持久化。理解它们的定位差异，是后续做数据恢复和选型的前提。

三种机制的定位差异

RDB（Redis Database）是某一时刻全量数据的二进制快照。它把当前内存中的键值对序列化成一个紧凑的 dump.rdb 文件。RDB 记录的是“某个时间点的数据长什么样”，属于时间点快照，不记录数据是怎么一步步变成这样的。它的优点是文件小、加载快、适合备份和全量迁移；缺点是两次快照之间的数据会丢失，且生成快照时 fork 子进程在数据量大时会有明显的资源开销。

AOF（Append Only File）记录的是写命令日志。每当有写操作执行，Redis 就把这条命令以 Redis 协议格式追加到 AOF 缓冲区，再按策略刷盘。重启时通过重放这些命令重建数据集。AOF 记录的是“数据如何变化”，因此数据完整性更高，默认每秒刷盘最多丢 1 秒数据；代价是文件通常比 RDB 大，恢复时需要逐条重放，速度慢于 RDB。

混合持久化是 Redis 4.0 引入的方案，它把两者结合：AOF 重写时，先以 RDB 格式写入当前全量数据作为 AOF 文件的头部，后续增量写命令再以 AOF 格式追加在后面。这样重启加载时，先快速加载 RDB 部分恢复大部分数据，再重放尾部少量 AOF 命令补齐增量，兼顾了 RDB 的加载速度和 AOF 的数据完整性。

关键参数与行为差异

RDB 的触发方式有两类：手动执行 SAVE（阻塞主线程）或 BGSAVE（fork 子进程后台生成），以及通过 save 配置项按“时间 + 变更次数”自动触发，例如 save 900 1 表示 900 秒内至少 1 个键被修改就触发一次快照。AOF 的刷盘策略由 appendfsync 控制：always 每条命令都刷盘，最安全但性能最差；everysec 每秒刷一次，是默认值，最多丢 1 秒数据；no 交给操作系统决定，性能最好但丢失风险最大。AOF 文件会随写命令累积而膨胀，需要通过 BGREWRITEAOF 重写压缩。

混合持久化由 aof-use-rdb-preamble yes 开启（Redis 4.0 及以上默认开启）。开启后，AOF 重写产生的文件不再是纯命令日志，而是“RDB 全量头 + AOF 增量尾”的结构。需要注意：混合持久化仍然属于 AOF 体系，文件路径仍是 appendonly.aof，只是内容格式变了。如果关闭该选项，AOF 重写会退回纯命令格式。

适用场景与选型原则

选型不是选“最好的”，而是选“最匹配业务容忍度的”。可以从三个维度判断：数据丢失容忍度（RPO）、恢复时间要求（RTO）、资源开销承受度。

• 只用 RDB：适合缓存类场景，数据可从源库重建，丢失几分钟可接受；也适合做冷备份和跨环境迁移。优点是文件小、恢复快、对主线程影响可控。
• 只用 AOF：适合对数据完整性要求高的场景，如订单、账户、会话等不能大量丢失的数据。代价是文件更大、恢复更慢，需要关注重写频率和磁盘 IO。
• 混合持久化：适合既要求数据完整、又要求快速恢复的生产环境，是目前多数线上 Redis 的推荐配置。它让 AOF 重写后的文件加载速度接近 RDB，同时保留秒级增量。

一个可参考的选型判断示例

假设某电商系统有三类 Redis 使用场景，可以按下面的思路做决策：