3. Redis持久化机制：RDB与AOF原理、混合持久化、数据恢复策略

Redis作为内存数据库，其高性能依赖于数据常驻内存。但一旦进程退出或机器宕机，内存数据将全部丢失。持久化机制是Redis保障数据安全的核心能力，它决定了在灾难发生后，系统能以多快的速度、恢复多少数据。本章深入剖析RDB、AOF及混合持久化的原理、配置与恢复策略。

3.1 RDB持久化：全量快照

RDB（Redis Database）通过创建某一时刻的内存快照（Snapshot）来实现持久化。它生成一个经过压缩的二进制文件（默认 dump.rdb），适合用于备份、灾难恢复和版本回滚。

3.1.1 触发方式

触发类型	命令/配置	特点
手动触发（save）	save	同步阻塞，主进程直接生成RDB，期间不处理任何请求。不推荐生产环境使用。
手动触发（bgsave）	bgsave	异步非阻塞，主进程fork子进程，由子进程负责生成RDB。生产环境首选手动触发方式。
自动触发（配置）	save <seconds> <changes>	满足时间与修改次数条件时自动执行bgsave。例如 save 900 1 表示900秒内至少1次修改则触发。
其他触发	主从全量复制、flushall、shutdown	特定场景下自动触发RDB生成。

3.1.2 RDB执行流程

3.1.3 RDB优缺点

3.2 AOF持久化：增量日志

AOF（Append Only File）以日志形式记录每次写操作指令，重启时通过回放所有指令来重建数据。它提供了更高的数据安全性，支持秒级甚至实时持久化。

3.2.1 AOF配置与刷盘策略

配置项	可选值	说明
appendonly	yes / no	是否开启AOF，默认关闭。
appendfsync	always	每次写命令都同步刷盘，最安全但性能最差。
appendfsync	everysec	每秒刷盘一次，兼顾性能与安全（默认值，推荐生产使用）。
appendfsync	no	由操作系统决定何时刷盘，性能最好但可能丢失大量数据。
auto-aof-rewrite-percentage	100	AOF文件体积增长比例触发重写。
auto-aof-rewrite-min-size	64mb	AOF文件最小重写体积。

3.2.2 AOF重写机制

AOF文件会随着写操作不断膨胀。Redis通过AOF重写（bgrewriteaof）来压缩文件：读取当前内存中的数据状态，生成恢复这些数据所需的最小指令集，然后用新文件替换旧文件。

3.3 混合持久化：RDB + AOF 融合

Redis 4.0 引入了混合持久化模式（aof-use-rdb-preamble yes）。它在AOF重写时，不再只记录纯指令，而是将当前内存数据以RDB格式写入AOF文件头部，后续增量操作再以AOF格式追加。重启时，先加载RDB快照，再回放少量AOF日志，兼顾了RDB的快速恢复与AOF的低数据丢失。

3.4 数据恢复策略与优先级

Redis启动时，根据持久化文件的存在情况决定恢复方式。恢复优先级如下：

场景	恢复方式	说明
仅开启AOF	加载AOF文件	回放所有写命令，重建数据集。
仅开启RDB	加载RDB文件	直接加载二进制快照，速度最快。
同时开启（混合模式）	优先加载AOF	AOF文件包含RDB头部，先加载RDB快照再回放AOF增量。
AOF文件损坏	redis-check-aof --fix	使用工具修复损坏的AOF文件，修复后重启。
RDB文件损坏	redis-check-rdb	使用工具检测并尝试修复RDB文件。

3.5 性能压测中的持久化影响

在微服务并发压测场景下，持久化机制对Redis性能有显著影响：

• RDB fork阻塞： 大内存实例（10GB+）fork子进程时，主进程会短暂阻塞，导致请求延迟出现毛刺。压测时需关注fork耗时。
• AOF刷盘延迟： appendfsync always 会使每次写操作等待磁盘IO，QPS下降明显。压测中建议使用 everysec。
• AOF重写资源竞争： 重写期间子进程消耗CPU和磁盘带宽，可能影响主进程响应。建议在低峰期触发重写。
• 混合持久化优势： 重启恢复时间从纯AOF的分钟级降至秒级，在压测集群故障恢复场景中至关重要。