Redis 主要采用RDB和AOF两种互补持久化机制：RDB定时生成紧凑快照，适合备份与快速恢复，但可能丢失最近数据；AOF记录写命令日志，数据更安全但体积大、恢复慢；生产环境推荐同时启用，启动时优先使用AOF恢复。
Redis 主要有两种持久化机制：RDB（快照）和 AOF（追加日志），它们解决的是同一个问题——内存数据断电或崩溃后不丢失，但思路完全不同。
RDB 是定时“拍照”，适合备份与快速恢复
RDB 在某个时间点把整个内存数据压缩成一个二进制快照文件（默认 dump.rdb），就像给数据库按个快门。它不记录操作过程，只保存结果。
- 触发方式包括：手动 BGSAVE（推荐）、SAVE（阻塞，慎用）、配置自动触发（如 red">save 60 10000 表示 60 秒内有 1 万次修改就存一次）、正常 SHUTDOWN 时也会自动执行
- 优点是文件小、加载快、对性能影响轻，特别适合做定时备份、主从全量同步、灾备恢复
- 缺点是可能丢数据——比如每 5 分钟存一次，宕机在第 4 分 59 秒，那这近 5 分钟的写入就没了
- 大内存实例 fork 子进程时会短暂增加内存占用，极端情况可能触发 OOM
AOF 是全程“录像”，侧重数据安全与可读性
AOF 把每个写命令（如 SET、LPUSH）以文本形式追加到日志文件（默认 appendonly.aof），重启时重放这些命令来还原数据，相当于回放操作录像。
- 写入策略分三种：always（每条都刷盘，最安全但慢）、everysec（默认，最多丢 1 秒）、no（交由系统调度，风险最高）
- 支持 AOF 重写（BGREWRITEAOF），自动压缩冗余命令（比如连续 SET key a、SET key b 只保留最后一条）
- 优点是数据丢失少、日志可读可编辑（误操作后可用 redis-check-aof --fix 修复）、支持混合持久化（Redis 7+ 默认启用，先 RDB 快照 + 后续 AOF 命令）
- 缺点是文件体积大、恢复速度慢（尤其命令多时）、高频写入下 fsync 可能成为 I/O 瓶颈
选哪个？看场景，不是非此即彼
生产环境通常同时开启 RDB 和 AOF，Redis 启动时会优先用 AOF 恢复（因它更完整），RDB 则作为辅助备份和冷备手段。
- 纯缓存场景，能接受几分钟丢失 → 只开 RDB 就够用
- 金融、订单等强一致性要求 → 必须开 AOF，且用 everysec 或 always
- Redis 7+ 推荐启用 aof-use-rdb-preamble yes，兼顾体积、速度与安全性
- 禁用某一种？可以，但别只依赖单一机制；关 RDB 就注释所有 save 行，关 AOF 就设 appendonly no
基本上就这些。RDB 和 AOF 不是对立选项，而是互补搭档——一个管“快”和“省”，一个管“全”和“稳”。
