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