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 记录所有写命令，以追加方式写入文件，安全性更高。
