RDB与AOF实践
理解 RDB 和 AOF 的原理只是第一步，生产中更重要的是配置、监控、重写、备份和恢复演练。持久化配置不当会让 Redis 在高峰时出现延迟尖刺或无法恢复。
# 1. 学习定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 运维实践 |
| 核心目标 | 先会用，再理解机制，最后能做工程取舍和故障分析 |
| 学习方法 | 带着业务场景看命令、SQL、数据结构、日志和运行时指标 |
# 2. 核心地图
RDB与AOF实践
├─ save
├─ bgsave
├─ appendonly
├─ appendfsync
├─ BGREWRITEAOF
├─ aof-use-rdb-preamble
├─ 备份
└─ 恢复演练
# 3. 小章节深度讲解
下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。
# 3.1. save
# 是什么
save 属于 Redis 持久化与恢复链路。RDB 偏快照，AOF 偏追加日志，二者都会带来 fork、COW、磁盘 IO 和恢复时间成本。
# 开发人员怎么用
开发人员要明确 Redis 数据是否允许丢失。纯缓存可以冷启动，业务状态、队列和锁相关数据则需要补偿、重建或更严格持久化。
# 运维人员怎么看
运维人员要监控 fork 耗时、AOF fsync 延迟、rewrite 状态、持久化目录空间和恢复加载时间。持久化失败必须告警。
# 常见风险
常见风险是实例内存接近上限时触发 fork，COW 内存峰值导致系统压力飙升甚至进程被杀。
# 3.2. bgsave
# 是什么
bgsave 属于 Redis 持久化与恢复链路。RDB 偏快照，AOF 偏追加日志，二者都会带来 fork、COW、磁盘 IO 和恢复时间成本。
# 开发人员怎么用
开发人员要明确 Redis 数据是否允许丢失。纯缓存可以冷启动，业务状态、队列和锁相关数据则需要补偿、重建或更严格持久化。
# 运维人员怎么看
运维人员要监控 fork 耗时、AOF fsync 延迟、rewrite 状态、持久化目录空间和恢复加载时间。持久化失败必须告警。
# 常见风险
常见风险是实例内存接近上限时触发 fork，COW 内存峰值导致系统压力飙升甚至进程被杀。
# 3.3. appendonly
# 是什么
appendonly 控制是否启用 AOF。开启后，Redis 会把写命令追加到 AOF 文件，重启时通过回放日志恢复数据；它提升数据可恢复性，也引入磁盘写入、fsync、rewrite 和恢复耗时成本。
# 开发人员怎么用
开发人员要先定义 Redis 数据的可丢失窗口。若业务状态依赖 Redis，开启 AOF 仍不等于万无一失，还要设计幂等写入、重建流程和与数据库真相源的校验。
# 运维人员怎么看
运维人员要关注 aof_enabled、aof_current_size、aof_base_size、aof_pending_bio_fsync、aof_last_bgrewrite_status、aof_last_write_status 和磁盘空间。AOF 策略要和 RPO、磁盘能力、重写窗口一起评估。
# 常见风险
常见风险是开启 AOF 后没有容量规划和 rewrite 策略，文件持续膨胀，磁盘写满或 rewrite 在高峰期触发，导致延迟抖动甚至写入失败。
# 3.4. appendfsync
# 是什么
appendfsync 属于 Redis 持久化与恢复链路。RDB 偏快照，AOF 偏追加日志，二者都会带来 fork、COW、磁盘 IO 和恢复时间成本。
# 开发人员怎么用
开发人员要明确 Redis 数据是否允许丢失。纯缓存可以冷启动，业务状态、队列和锁相关数据则需要补偿、重建或更严格持久化。
# 运维人员怎么看
运维人员要监控 fork 耗时、AOF fsync 延迟、rewrite 状态、持久化目录空间和恢复加载时间。持久化失败必须告警。
# 常见风险
常见风险是实例内存接近上限时触发 fork，COW 内存峰值导致系统压力飙升甚至进程被杀。
# 3.5. BGREWRITEAOF
# 是什么
BGREWRITEAOF 属于 Redis 持久化与恢复链路。RDB 偏快照，AOF 偏追加日志，二者都会带来 fork、COW、磁盘 IO 和恢复时间成本。
# 开发人员怎么用
开发人员要明确 Redis 数据是否允许丢失。纯缓存可以冷启动，业务状态、队列和锁相关数据则需要补偿、重建或更严格持久化。
# 运维人员怎么看
运维人员要监控 fork 耗时、AOF fsync 延迟、rewrite 状态、持久化目录空间和恢复加载时间。持久化失败必须告警。
# 常见风险
常见风险是实例内存接近上限时触发 fork，COW 内存峰值导致系统压力飙升甚至进程被杀。
# 3.6. aof-use-rdb-preamble
# 是什么
aof-use-rdb-preamble 属于 Redis 持久化与恢复链路。RDB 偏快照，AOF 偏追加日志，二者都会带来 fork、COW、磁盘 IO 和恢复时间成本。
# 开发人员怎么用
开发人员要明确 Redis 数据是否允许丢失。纯缓存可以冷启动，业务状态、队列和锁相关数据则需要补偿、重建或更严格持久化。
# 运维人员怎么看
运维人员要监控 fork 耗时、AOF fsync 延迟、rewrite 状态、持久化目录空间和恢复加载时间。持久化失败必须告警。
# 常见风险
常见风险是实例内存接近上限时触发 fork，COW 内存峰值导致系统压力飙升甚至进程被杀。
# 3.7. 备份
# 是什么
备份 属于 Redis 持久化与恢复链路。RDB 偏快照，AOF 偏追加日志，二者都会带来 fork、COW、磁盘 IO 和恢复时间成本。
# 开发人员怎么用
开发人员要明确 Redis 数据是否允许丢失。纯缓存可以冷启动，业务状态、队列和锁相关数据则需要补偿、重建或更严格持久化。
# 运维人员怎么看
运维人员要监控 fork 耗时、AOF fsync 延迟、rewrite 状态、持久化目录空间和恢复加载时间。持久化失败必须告警。
# 常见风险
常见风险是实例内存接近上限时触发 fork，COW 内存峰值导致系统压力飙升甚至进程被杀。
# 3.8. 恢复演练
# 是什么
恢复演练 属于 Redis 持久化与恢复链路。RDB 偏快照，AOF 偏追加日志，二者都会带来 fork、COW、磁盘 IO 和恢复时间成本。
# 开发人员怎么用
开发人员要明确 Redis 数据是否允许丢失。纯缓存可以冷启动，业务状态、队列和锁相关数据则需要补偿、重建或更严格持久化。
# 运维人员怎么看
运维人员要监控 fork 耗时、AOF fsync 延迟、rewrite 状态、持久化目录空间和恢复加载时间。持久化失败必须告警。
# 常见风险
常见风险是实例内存接近上限时触发 fork，COW 内存峰值导致系统压力飙升甚至进程被杀。
# 3.9. 本篇学习实验
建议准备一个独立 Redis 实例，构造小 key、大 key、热点 key、过期 key 和慢命令，观察 INFO、SLOWLOG、LATENCY、内存变化和客户端超时。每个实验都要记录命令复杂度和返回数据量。
开发侧实验重点是理解数据结构和命令边界，运维侧实验重点是理解延迟、内存和复制如何变化。真正掌握本篇内容，应该能从延迟尖刺反推大 key、慢命令、持久化或网络问题。
# 4. 核心机制
BGSAVE通过子进程生成 RDB，主进程继续处理请求，但 fork 和 COW 会带来瞬时成本。- AOF 根据
appendfsync控制刷盘频率，常见策略是 always、everysec、no。 - AOF rewrite 会压缩历史命令，避免文件无限增长。
- 恢复时 Redis 通常优先加载 AOF，因为它可能包含比 RDB 更新的数据。
# 5. 工程实践
- 状态型实例优先开启 AOF everysec 或混合持久化，并压测延迟影响。
- 为 RDB/AOF 文件配置独立磁盘或至少独立空间告警。
- 定期复制持久化文件到异地存储，避免单机故障同时损坏数据和备份。
- 恢复演练要记录文件大小、加载时长、数据校验和业务预热时间。
# 6. 常见坑
- AOF rewrite 和业务高峰重叠，造成磁盘 IO 抖动。
- 持久化目录空间不足，Redis 写入失败或持久化失败。
- 备份只拷贝 RDB，忽略 AOF 和配置文件。
- 恢复后没有校验 key 数、样本数据和业务状态。
# 7. 专家视角
- 持久化实践要以“恢复结果”倒推配置，而不是看默认值。
- 专家会将 Redis 恢复过程写成剧本：停止、备份现场、替换文件、加载、校验、放量。
- 大规模 Redis 集群要考虑批量恢复时对数据库回源和下游系统的冲击。
# 8. Tips 快问快答
Q：appendfsync everysec 会丢数据吗？
A：极端故障下可能丢失约一秒内写入，具体取决于系统和故障时机。
Q：AOF rewrite 会阻塞吗？
A：主要由子进程执行，但 fork、COW 和磁盘 IO 仍可能影响延迟。
Q：备份 Redis 只要 RDB 文件吗？
A：还要看是否开启 AOF，并保留配置、版本和恢复步骤。
# 9. 阶段小结
RDB与AOF实践 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。