Redis持久化机制详解：RDB与AOF如何保障数据安全
RDB快照：高效全量备份
RDB（Redis Database）是一种基于时间点的全量数据快照机制。它将某一时刻的内存数据完整地保存为一个二进制文件，恢复时只需将该文件加载回内存即可，无需逐条执行命令，因此恢复速度远高于其他方式。
RDB的生成可通过两个核心命令触发：
- SAVE：由主线程同步执行，会阻塞所有客户端请求直到写入完成，通常仅在关闭服务或手动调试时使用。
- BGSAVE：通过
fork()系统调用创建子进程，在后台异步完成数据写入，主线程继续处理读写请求，避免服务中断。
写时复制（Copy-on-Write）原理
当BGSAVE启动后，操作系统利用写时复制技术实现高效的内存隔离：
- 子进程诞生时共享父进程的内存页表，不立即复制实际数据。
- 主进程在接收到写操作时，若涉及已被共享的数据页，则内核为其分配新的物理内存空间，并更新映射关系。
- 子进程则持续遍历原始内存视图，将其内容写入RDB文件，不受后续变更影响。
这种机制显著降低了fork开销，但存在潜在问题：
- 若大量数据被修改，可能导致内存占用接近翻倍，引发OOM风险。
- 由于快照基于
fork瞬间的状态，此后的新写入不会包含在本次RDB中，宕机时可能丢失这部分数据。
建议合理设置自动触发策略，例如：
save 900 1 # 15分钟内至少1次更改
save 300 10 # 5分钟内至少10次更改
save 60 10000 # 1分钟内至少10000次更改
同时应避开业务高峰期执行，防止I/O和CPU资源争抢影响性能。
AOF日志：高可靠增量记录
AOF（Append Only File）通过追加方式记录每一条写命令，类似数据库的事务日志。重启时重新执行这些命令即可重建数据状态，理论上可实现零数据丢失。
写入流程分为三步：
- 命令执行后写入缓冲区
server.aof_buf； - 调用
write()将数据送入内核page cache； - 根据配置策略决定何时调用
fsync()强制刷盘。
三种同步策略对比
| 策略 | 说明 | 数据安全性 | 性能影响 |
|---|---|---|---|
appendfsync always |
每次写操作都同步刷盘 | 最高，几乎无丢失 | 严重，磁盘I/O瓶颈 |
appendfsync everysec |
每秒批量刷盘一次 | 最多丢失1秒数据 | 较低，推荐使用 |
appendfsync no |
交由操作系统调度 | 不确定，依赖系统策略 | 最小 |
其中everysec是默认且最常用的选项，在可靠性和性能之间取得良好平衡。
AOF重写压缩机制
随着写入增多，AOF文件会不断膨胀。Redis提供重写功能来精简日志：
- 启动条件可通过配置控制：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
即当前文件大小比上次重写后增长一倍且超过64MB时触发。
重写过程由独立子进程bgrewriteaof完成：
- 扫描当前数据库所有键值对；
- 以最新状态生成对应的写命令（如
SET key value），替代原有的多次修改指令； - 将结果写入临时文件，完成后原子替换原AOF文件。
这样既减小了文件体积，又提升了恢复效率。
混合持久化：兼顾速度与完整性
从Redis 4.0起引入混合持久化模式，结合RDB快速恢复和AOF低延迟的优点。
其工作原理如下：
- 在AOF重写期间，先以RDB格式将全量数据写入新AOF文件头部；
- 随后的增量操作仍按AOF协议追加至文件末尾；
- 最终生成的AOF文件前半部分为RDB数据块，后半为AOF日志流。
启用方式：
aof-use-rdb-preamble yes
优点显而易见：
- 恢复时优先读取RDB段，大幅提升加载速度；
- 保留AOF尾部增量，确保尽可能少的数据丢失。
但也带来一些限制：
- 文件结构复杂，难以人工解析；
- 不兼容Redis 4.0以前版本，迁移需谨慎。
持久化选择与优先级
当Redis实例同时存在RDB和AOF文件时，启动时将优先采用AOF进行恢复，因其通常包含更完整的数据变更历史。
总结不同机制的核心差异：
| 特性 | RDB | AOF |
|---|---|---|
| 存储内容 | 二进制快照 | 文本命令序列 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 取决于频率 | 高（尤其everysec） |
| 资源消耗 | CPU/I/O高，内存瞬时双倍 | 持续I/O压力 |
实践中推荐：
- 开启AOF并设为
everysec策略作为主要保障； - 配合定时RDB备份用于灾难恢复；
- 有条件可启用混合持久化进一步优化恢复体验。
