一、前言：持久化不是“开不开”，而是“怎么配”
Redis 作为内存数据库，默认重启即丢数据。
为保障数据安全，Redis 提供了两种持久化机制：
- RDB（Redis Database）：全量快照
- AOF（Append Only File）：增量日志
很多团队在上线时随意选择一种，结果要么数据丢失惨重，要么性能被拖垮。
本文将从原理、性能、可靠性、运维四个维度，深度对比 RDB 与 AOF，并给出生产环境选型建议。
二、核心原理对比
| 本质 | 时间点快照（Point-in-Time Snapshot） | 操作日志（Write-Ahead Log） |
| 触发方式 | 手动 SAVE/BGSAVE 或配置 save 规则 | 每条写命令追加到文件 |
| 文件内容 | 二进制格式的内存数据快照 | 文本格式的 Redis 命令（RESP 协议） |
| 恢复方式 | 直接加载二进制数据到内存 | 重放所有写命令重建状态 |
| 一致性模型 | 强一致性（fork 时刻的数据） | 最终一致性（取决于 fsync 策略） |
💡 关键区别：
- RDB 是“拍照片”——某一瞬间的状态
- AOF 是“录视频”——所有操作的历史记录
三、详细特性对比表
| 数据安全性 | 可能丢失最后一次快照后的数据（如几分钟） | 最多丢失 1 秒（everysec）或几乎不丢（always） | ✅ AOF |
| 文件大小 | 小（二进制压缩，仅存有效数据） | 大（文本命令，含冗余操作） | ✅ RDB |
| 恢复速度 | ⚡ 极快（直接加载） | 🐢 慢（需重放命令，文件越大越慢） | ✅ RDB |
| 对性能影响 | 仅 fork 时短暂阻塞（大内存实例明显） | 持续写磁盘（everysec 影响小） | ⚖️ 各有场景 |
| 备份友好性 | ✅ 单文件，易压缩、易传输、易异地备份 | ❌ 文件大，且需保证完整性 | ✅ RDB |
| 容灾恢复 | 适合做定期冷备 | 适合做近实时恢复 | — |
| 主从复制 | 全量同步依赖 RDB 文件 | 增量同步使用命令流 | RDB（全量）+ AOF（增量） |
| 支持版本 | 所有 Redis 版本 | Redis 1.1+ | — |
四、典型场景分析
场景 1：用户会话缓存（可丢失）
- 特点：数据可重建，丢失无影响
- 推荐：仅 RDB（甚至可关闭持久化）
- 理由：追求极致性能，无需高可靠性
场景 2：电商商品库存（不能丢）
- 特点：每次扣减必须持久化
- 推荐：AOF + appendfsync always
- 理由：宁可牺牲性能，也要保证数据准确
场景 3：社交 App 用户动态（高并发写）
- 特点：写多读多，可容忍少量丢失
- 推荐：AOF + appendfsync everysec + 混合持久化
- 理由：平衡性能与可靠性，恢复速度也快
场景 4：配置中心（低频写，高可靠）
- 特点：写少但关键，需快速恢复
- 推荐：RDB + AOF 混合模式
- 理由：RDB 快速启动，AOF 保证不丢最新配置
五、混合持久化：Redis 4.0+ 的终极方案
从 Redis 4.0 开始，官方引入 RDB + AOF 混合持久化，完美融合两者优势：
# redis.conf
aof-use-rdb-preamble yes
appendonly yes
文件结构：
[REDIS][rdb_version][RDB 快照数据…][EOF][AOF 增量命令…]
优势：
| 恢复速度 | 先加载 RDB 部分（秒级），再重放少量 AOF 命令 |
| 数据安全 | 保留 AOF 的高可靠性 |
| 文件大小 | 比纯 AOF 更紧凑 |
✅ 结论：对于绝大多数生产环境，应启用混合持久化！
六、生产环境配置建议
推荐组合（90% 场景适用）：
# 同时开启 RDB 和 AOF
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
# 关键！开启混合持久化
aof-use-rdb-preamble yes
# AOF 自动重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
特殊场景调整：
| 金融/支付 | appendfsync always，关闭 no-appendfsync-on-rewrite |
| 日志缓存 | 仅 RDB，或关闭持久化 |
| 大内存实例（>32GB） | 监控 latest_fork_usec，考虑分片降低单实例内存 |
七、常见误区澄清
❌ 误区 1：“开了 AOF 就不用 RDB”
- 事实：RDB 仍是主从全量同步和备份恢复的基础。即使开启 AOF，RDB 仍有价值。
❌ 误区 2：“AOF 重写会读原 AOF 文件”
- 事实：AOF 重写直接遍历内存，完全不读原文件！
❌ 误区 3：“混合持久化 = RDB + AOF 同时写两个文件”
- 事实：混合模式下，只有一个 AOF 文件，其头部是 RDB 格式。
八、如何验证持久化是否生效？
# 查看持久化状态
127.0.0.1:6379> INFO PERSISTENCE
# 关键字段解读：
rdb_last_save_time # 上次 RDB 保存时间
aof_enabled # AOF 是否开启
aof_current_size # AOF 文件大小
aof_last_bgrewrite_status # AOF 重写是否成功
🔍 建议：将上述指标接入监控系统（如 Prometheus + Grafana），设置告警。
九、结语
感谢您的阅读！如果你有任何疑问或想要分享的经验，请在评论区留言交流！
