持久化 RDB 与 AOF

用途：判断“重启会丢多少数据”“为什么 Redis 卡顿”

两种机制

机制	原理	优点	缺点
RDB	某时刻全量快照（fork 子进程写压缩文件）	文件紧凑、恢复快、适合备份与复制种子	两次快照之间的数据会丢；fork 与写时复制有代价
AOF	追加写命令（或每秒/每次刷盘），重启重放	丢数据窗口小、可读可修	文件大、恢复慢、重写有 IO 峰值

同时开启时重启以 AOF 为准（数据更全）。

关键参数与取舍

参数	选项	影响
appendfsync	always / everysec（默认）/ no	丢数据窗口 0 秒 / ≤1 秒 / 取决于 OS；always 吞吐损失明显
save（RDB 触发点）	如 3600 1 300 100 60 10000	触发过于频繁会反复 fork
auto-aof-rewrite-percentage/min-size	重写阈值	阈值过小导致频繁重写
aof-use-rdb-preamble	混合持久化	AOF 重写时以 RDB 为底 + 增量命令，恢复快且丢数据少

fork 与写时复制的隐性代价

fork 本身是 O(页表) 操作，实例越大越慢（GB 级可能几十到上百毫秒卡顿）；fork 后子进程读内存，父进程写入触发复制，写密集场景内存可能瞬时翻倍。因此：

• 大实例（>10GB）慎做频繁 RDB；考虑拆分实例降低单实例体积。
• 关闭 THP（透明大页）以避免复制页语义劣化（官方建议）。
• 监控 latest_fork_usec、mem_fragmentation_ratio。

可靠性现实

Redis 持久化是“尽力而为”，不是数据库级保证：

1. everysec 仍可能丢 1 秒；崩溃在刷盘前。
2. 主从复制是异步的，主库故障时未同步数据丢失。
3. AOF 重放在极端情况下可能失败（可用 redis-check-aof 修复，但会截断）。

需要强持久性的数据必须落在关系库或其他持久存储，Redis 只做缓存/加速层。

备份运维要点

• RDB 文件异地保存并校验（大小、时间、可加载）。
• 恢复演练：定期用备份起一个实例验证数据。
• 复制 + 持久化组合：从库承担持久化与备份，减轻主库 fork 压力（replica-priority、从库关闭 AOF 等策略需权衡）。

常见误区

误区	修正
关闭持久化“提升性能”	重启即全丢，缓存雪崩风险远大于那点吞吐收益
只靠 RDB 做灾备	丢数据窗口等于快照间隔
在物理机上放 RDB 就算备份	必须异地、可验证
大实例频繁 BGSAVE	fork 卡顿与内存翻倍，改低峰或用从库执行
认为 AOF 一定比 RDB 安全	appendfsync no 下由 OS 决定，可能丢很多

延伸阅读

• Redis 官方文档：Persistence、RDB and AOF 组合、Latency and Performance（fork 部分）
• 《Redis 设计与实现》持久化章节