Redis持久化机制

Redis是典型的内存型数据库，所有数据默认存储在内存中，一旦进程崩溃、服务器宕机，内存数据会彻底丢失。持久化机制的核心作用，就是将内存中的数据异步/同步写入磁盘，实现故障后的数据恢复，兼顾Redis的高性能与数据可靠性。

Redis官方提供两种基础持久化方案：RDB（快照持久化）和AOF（日志持久化），4.0版本后新增混合持久化，融合两者优势，成为生产环境主流选型。下文从原理、触发方式、配置、优缺点、适用场景逐一拆解。

一、RDB持久化：全量快照式持久化

RDB（Redis DataBase）是Redis默认的持久化方式，核心逻辑是定时生成内存数据的全量二进制快照，压缩后写入磁盘文件（默认dump.rdb），恢复时直接加载快照文件到内存，速度极快。

1.1 核心触发方式

（1）手动触发

SAVE命令：同步执行快照，阻塞Redis主线程，期间无法处理任何客户端请求，生产环境严禁使用。
BGSAVE命令：异步执行快照，通过fork()创建子进程，子进程负责写入快照，主线程继续处理请求，无阻塞，生产环境推荐。

（2）自动触发（配置规则）

通过redis.conf配置触发阈值，满足条件自动执行BGSAVE，默认配置如下：

# 900秒内至少1次写操作
save 900 1
# 300秒内至少10次写操作
save 300 10
# 60秒内至少10000次写操作
save 60 10000

其他自动触发场景：主从复制时主节点自动生成RDB、执行FLUSHALL命令、Redis正常关闭（SHUTDOWN）。

1.2 执行流程

主线程触发BGSAVE，调用fork()创建子进程，fork瞬间会短暂阻塞主线程（数据量越大阻塞越久）。
子进程基于fork的内存副本，生成临时快照文件，写入完成后替换旧dump.rdb。
快照生成期间，主线程正常处理读写请求，新写入数据不会同步到当前快照，保证快照一致性。

1.3 核心优缺点

✅ 优势

快照文件体积小、压缩率高，磁盘占用低，备份传输便捷。
数据恢复速度极快，适合大规模数据冷启动。
对Redis性能影响小，异步执行不阻塞主线程。

❌ 劣势

数据丢失风险高：两次快照间隔内宕机，间隔期数据全部丢失。
fork子进程会占用额外内存，大数据量下可能引发内存飙升。
不适合实时性要求极高的场景。

1.4 适用场景

数据允许分钟级丢失、冷备迁移、大规模数据恢复、对性能要求极高的业务场景。

二、AOF持久化：增量日志式持久化

AOF（Append Only File）默认关闭，核心逻辑是记录所有写命令（增删改）到日志文件（默认appendonly.aof），恢复时按顺序回放日志命令，重建内存数据，数据可靠性远高于RDB。

2.1 核心刷盘策略

AOF通过fsync()函数将日志刷入磁盘，刷盘频率直接决定数据可靠性和性能，redis.conf支持三种配置：

每次写刷盘	always	每执行一条写命令，立即刷盘	最高，几乎不丢数据	最大，严重降低吞吐量
每秒刷盘	everysec	每秒异步批量刷盘（默认）	高，最多丢失1秒数据	极低，生产环境首选
操作系统控制	no	由OS内核决定刷盘时机	最低，丢失数据不可控	最高

2.2 AOF重写机制

随着业务运行，AOF日志会无限膨胀，占用大量磁盘，且恢复速度变慢。Redis通过AOF重写压缩日志：

原理：忽略无效命令（重复写、过期删除），只保留最终数据的最简命令，生成新AOF文件替换旧文件。
触发：手动执行BGREWRITEAOF命令，或配置自动重写阈值（auto-aof-rewrite-min-size、auto-aof-rewrite-percentage）。
特性：重写由子进程异步执行，不阻塞主线程。

2.3 核心优缺点

✅ 优势

数据可靠性极高，默认最多丢失1秒数据。
日志文件为可读文本，可手动修改修复异常数据。
无全量快照的内存开销，适合实时性要求高的场景。

❌ 劣势

AOF文件体积远大于RDB，备份传输成本高。
数据恢复速度慢，需逐条回放命令。
每秒刷盘策略仍有极小概率丢数据，always策略牺牲性能。

2.4 适用场景

数据不允许丢失、实时性要求高、数据增量变更频繁的核心业务场景。

三、混合持久化：Redis4.0+最优解

Redis4.0及以上版本支持RDB+AOF混合持久化，完美融合两者优势，解决单一方案的痛点。

3.1 核心原理

AOF重写时，先将当前内存数据以RDB快照格式写入AOF文件头部，后续新增的写命令以AOF增量日志格式追加到文件尾部。恢复时，先加载RDB全量数据，再回放AOF增量日志，兼顾恢复速度和数据可靠性。

3.2 开启配置

# 开启AOF
appendonly yes
# 开启混合持久化
aof-use-rdb-preamble yes

3.3 核心优势

恢复速度接近RDB，远快于纯AOF。
数据可靠性与纯AOF一致，最多丢失1秒数据。
文件体积适中，避免纯AOF的膨胀问题。

四、RDB与AOF核心对比

核心选型对比表

数据恢复速度：RDB > 混合持久化 > 纯AOF
数据可靠性：纯AOF(always) > 混合持久化 > 纯AOF(everysec) > RDB
磁盘占用：纯AOF > 混合持久化 > RDB
性能损耗：纯AOF(always) > 混合持久化 > 纯AOF(everysec) > RDB

五、生产环境实战建议

首选方案：开启混合持久化（AOF+RDB），搭配everysec刷盘策略，平衡可靠性与性能。
备份策略：定期备份RDB文件，AOF文件保留历史版本，防止文件损坏。
避坑要点：避免频繁触发RDB快照和AOF重写；大数据实例优化fork内存占用；不要同时关闭两种持久化。
故障恢复：优先加载混合持久化文件，若文件损坏可使用redis-check-aof工具修复。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

Redis集群文章被收录于专栏

本专栏聚焦 Redis Cluster 官方分布式方案，拆解去中心化架构、16384 哈希槽分片、Gossip 协议通信、主从复制与自动故障转移核心原理。从集群搭建、扩缩容实战，到生产环境性能调优、故障排查、高可用设计，覆盖原理剖析、实操步骤、面试高频考点与最佳实践，助力开发者突破单机瓶颈，构建支撑海量数据与高并发的分布式缓存体系，适配电商、社交等业务场景。