Redis 7 持久化机制详解
本文基于 Redis 7.0.15 版本进行讲解。
Redis 作为内存数据库,读写速度极快,但内存断电即失的特性决定了必须引入持久化机制。简单来说,就是把内存数据落盘,确保服务重启或崩溃后数据不丢失。Redis 主要提供两种持久化方案:RDB(快照)和 AOF(追加日志),而在 Redis 7 中又引入了混合持久化来兼顾两者优势。
RDB 快照机制
RDB 的核心是生成某个时间点的完整数据快照。由于 Redis 是单线程模型,如果在主线程直接进行文件 IO 会阻塞客户端请求,所以它采用了 fork + 写时复制(Copy On Write, COW)机制。
原理与流程
当触发持久化时,Redis 调用 fork 创建子进程。父子进程共享内存页,此时父进程继续处理业务请求。一旦父进程修改了某个内存页面,操作系统会将该页面复制一份,父进程操作副本,而子进程始终指向原始数据。这样既保证了快照的一致性,又避免了全量拷贝的性能开销。
随着被修改的页面增多,内存占用会暂时翻倍,直到拷贝完成,临时页面释放。
最终,子进程将内存数据写入临时文件,完成后通过原子性的 rename 操作替换正式文件,确保不会出现损坏的 RDB 文件。
触发方式
RDB 触发分为自动和手动两类:
- 手动触发:
save:同步阻塞,期间 Redis 不可用,生产环境慎用。bgsave:异步非阻塞,推荐方式,后台 fork 子进程执行。
# 正常关闭时默认执行 save
shutdown
# 或者显式指定
shutdown save
- 自动触发:在
redis.conf中配置save规则,例如 900 秒内至少 1 个键变化,或 300 秒内至少 100 个键变化,满足条件即触发bgsave。
优缺点分析
优势:恢复速度快,二进制格式支持压缩,备份对主进程影响小。 局限:无法做到实时一致性,宕机可能丢失最后一次快照后的数据。
AOF 追加日志
AOF 记录所有写命令,以追加方式写入文件,安全性更高。


