Redis 持久化是什么
Redis 提供两种持久化机制：RDB 按条件生成时间点快照，文件紧凑、恢复快；AOF 追加记录写命令，丢数窗口更小但文件更大、恢复更慢。两者可以同时开启，同时存在时启动会优先加载 AOF。生产环境通常同时启用，用 RDB 做快速恢复、用 AOF 兜住丢失窗口。
基本信息
| RDB 触发 | 按 save 规则自动触发，也可手动执行保存命令 |
|---|---|
| AOF 刷盘 | appendfsync 可取 always、everysec、no |
| 加载优先级 | 同时存在时优先加载 AOF |
| 重写机制 | AOF 体积膨胀后由重写生成精简版本 |
| 适用 | 缓存与队列类数据，衡量重建成本后再决定持久化强度 |
redis.conf 关键配置
redis.conf 关键配置
# RDB：900 秒 1 次修改，300 秒 10 次，60 秒 1 万次触发
save 900 1
save 300 10
save 60 10000
# AOF
appendonly yes
appendfsync everysecRDB 与 AOF 对比
| 维度 | RDB | AOF |
|---|---|---|
| 内容 | 紧凑二进制快照 | 追加写命令日志 |
| 恢复速度 | 快 | 慢，需要逐条重放 |
| 丢失窗口 | 取决于快照间隔 | everysec 约 1 秒 |
| 体积与 IO | 体积小，写盘集中 | 体积大，持续追写 |
运维要点
- 把 RDB 与 AOF 文件复制到独立存储：只留在本机会随实例磁盘一起失效
- 理解 fork 开销：生成快照需要复制页表，大内存实例会产生可观测的延迟抖动
- 监控重写与保存失败：写盘失败通常源于磁盘空间不足或权限问题
- 主从与持久化分开考虑：复制提高可用性，持久化保证重启不丢数据
- 评估重建成本：纯缓存数据可从源头重建时，可适当放宽持久化强度
误认为开了 AOF 就不丢数据：everysec 仍有约 1 秒窗口，操作系统层面的缓冲丢失影响更大；对账类数据不能只依赖 Redis 持久化。
appendfsync always 数据更稳但写性能明显下降；everysec 是延迟与安全的常见折中，也需要接受秒级的丢失窗口。
常见排查场景
- 重启后数据回到很早的状态：检查是否只有 RDB 生效，AOF 是否因损坏被拒绝加载
- 快照生成时出现明显延迟：与 fork 开销、内存规模与写时复制压力相关
- 日志中出现保存失败告警：多数由磁盘空间不足或目录权限变化引起
- 恢复耗时远超预期：AOF 体积过大时需要先重写再恢复，而不是直接加载