Redis持久化机制RDB和AOF有什么区别？

RDB恢复快但易丢数据，因其是内存全量二进制快照，启动时直接加载dump.rdb跳过命令重放，不记录两次快照间的写操作；默认save 900 1配置下最坏可丢失15分钟数据。

RDB 和 AOF 不是“选一个就好”的关系，而是解决不同问题的两种机制：RDB 保恢复速度和磁盘开销，AOF 保数据不丢。生产环境几乎都得配 AOF，RDB 通常作为补充或灾备手段。

为什么 RDB 恢复快但容易丢数据

RDB 是内存数据的二进制快照，启动时直接加载 dump.rdb 文件，跳过命令重放过程。它不记录中间状态，只保存某一时刻的全量数据 —— 所以恢复快，但两次快照之间发生的写操作全没了。

1. 默认配置 save 900 1 意味着：900 秒内至少 1 次修改才触发一次 bgsave，最坏可能丢近 15 分钟数据
2. save 命令会阻塞所有客户端请求，线上严禁使用；bgsave 虽异步，但 fork 子进程在内存 >10GB 时可能卡顿 100ms+，影响延迟敏感业务
3. 文件体积小（比如 2GB 内存常压成 300MB dump.rdb），适合定时 scp 到异地、做冷备

AOF 为什么安全但慢、占空间大

AOF 把每个写命令（如 set key val）按 Redis 协议格式追加到 appendonly.aof，重启时逐条重放。它本质是操作日志，所以能逼近“不丢”，但代价明显。

1. 同步策略决定安全性：appendfsync always 每次写都落盘，最安全但性能暴跌；appendfsync everysec（默认）折中，最多丢 1 秒数据；appendfsync no 交给 OS，风险最高
2. AOF 文件会不断膨胀，Redis 用 bgrewriteaof 后台重写 —— 它不是简单压缩，而是读取当前内存状态，生成最小等效指令集，但重写过程仍需 fork，同样有内存压力
3. 1GB 数据的 AOF 文件可能达 3–5GB（尤其含大量 del、incr 等冗余操作），恢复时要重放几十万条命令，比 RDB 慢数倍

RDB + AOF 混合模式怎么配才不踩坑

Redis 4.0+ 支持混合持久化：aof-use-rdb-preamble yes。它让 AOF 文件前半部分是 RDB 快照，后半部分是增量命令 —— 兼顾加载速度和数据完整性。但启用前必须确认几点：

1. 必须先开启 AOF（appendonly yes），否则混合模式无效
2. 混合 AOF 文件仍由 bgrewriteaof 生成，不是自动切换；旧纯文本 AOF 不会自动升级，需手动触发重写
3. 混合格式只被 Redis 4.0+ 识别，降级到老版本（如 3.2）会无法加载，跨版本迁移务必验证
4. 不要同时关掉 RDB 自动触发（注释掉所有 save 行）—— 混合模式依赖 RDB 快照能力，且 bgsave 仍是紧急备份的唯一可靠手段

真正麻烦的从来不是选 RDB 还是 AOF，而是没想清楚“能接受丢多少数据”和“恢复时间能不能超 30 秒”。很多故障复盘发现，问题不在机制本身，而在没关掉 stop-writes-on-bgsave-error yes 却没监控 bgsave 失败，结果磁盘满后 RDB 彻底停摆，只剩 AOF 独木难支。