Redis持久化RDB与AOF对比及混合策略

一、Redis为什么需要持久化

Redis 常被当作缓存，但在会话、计数、队列和排行榜等场景中，数据丢失会造成业务影响。持久化的目标是在性能和可靠性之间取平衡。Redis 主要提供 RDB 和 AOF 两种方式，生产环境还可以启用混合持久化。

二、RDB适合快速恢复

RDB 会在指定条件下生成内存快照。它适合备份、灾备复制和快速重启。生成快照时 Redis 会 fork 子进程，父进程继续处理请求，但如果内存很大，fork 和写时复制会带来瞬时资源压力。

save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /data

上面配置表示在不同时间窗口内达到写入次数就触发快照。RDB 的核心问题是数据恢复点不够细。如果 Redis 在两次快照之间宕机，这段时间的写入可能丢失。因此它更适合缓存型或允许少量丢失的业务。

三、AOF更关注写入完整性

AOF 会把写命令追加到日志文件。appendfsync 决定刷盘策略：always 最安全但最慢，everysec 是常见折中，no 依赖操作系统刷盘，风险更高。

appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF 文件会随着写入增长，Redis 会通过 rewrite 压缩历史命令。例如对同一个 key 多次修改，最终只保留恢复当前状态所需的最小命令集合。需要注意的是，AOF rewrite 也会消耗 CPU、磁盘和内存，低峰期触发更稳妥。

四、混合持久化与生产建议

Redis 4.0 之后支持混合持久化，AOF rewrite 后的文件前半部分是 RDB 格式快照，后半部分是增量 AOF。恢复时先加载快照，再回放增量，速度和完整性都更均衡。

appendonly yes
aof-use-rdb-preamble yes
appendfsync everysec

生产选择要看业务。纯缓存可以只开 RDB，核心状态建议 AOF everysec 或混合持久化，并配合主从复制、定期备份和恢复演练。不要把“开了持久化”等同于“不会丢数据”，因为磁盘故障、误删、主从延迟和配置错误仍然存在。可靠性来自持久化、复制、备份、监控和演练的组合。

还要监控持久化本身的健康状态，例如最近一次 RDB 是否成功、AOF rewrite 是否失败、磁盘是否接近写满、fork 耗时是否异常。Redis 写入很快，磁盘却可能成为隐藏瓶颈。对关键业务，备份文件应定期复制到独立存储，并实际演练从备份恢复到新实例。没有恢复验证的备份，只能算一个未经证明的希望。

如果部署在容器中，要确认数据目录挂载到持久卷，并设置合理的磁盘告警。容器重建不应导致持久化文件丢失。

📌 本文是《后端排障实战》系列，持续更新，关注不迷路。
👉 下一篇：《缓存与数据库不一致时到底信谁》，讲写入失败、延迟删除和并发覆盖下的一致性取舍。
💬 你在实际项目里遇到过 Redis 重启后恢复太慢或 AOF 文件异常膨胀的问题吗？评论区聊聊。
（觉得有用点个赞+收藏，方便回头查阅）
🔧 相关可运行源码/资料已整理成资源包，可在我主页的资源里自取。