一、Redis为什么需要持久化Redis 常被当作缓存但在会话、计数、队列和排行榜等场景中数据丢失会造成业务影响。持久化的目标是在性能和可靠性之间取平衡。Redis 主要提供 RDB 和 AOF 两种方式生产环境还可以启用混合持久化。方式原理优点风险RDB定期生成快照文件小、恢复快可能丢失快照后的数据AOF追加写命令数据更完整文件较大、恢复较慢混合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 64mbAOF 文件会随着写入增长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 文件异常膨胀的问题吗评论区聊聊。觉得有用点个赞收藏方便回头查阅 相关可运行源码/资料已整理成资源包可在我主页的资源里自取。