Redis 持久化 RDB 与 AOF 及选型
持久化题主要考 RDB、AOF 原理和优缺点，偶尔问 Redis 4.0 以后的混合持久化。结合「缓存丢了怎么办」的业务心态一起答更顺。
题目
Redis 的持久化方式有哪些？优缺点？
参考答案（口述要点）
- RDB：定时快照，恢复快，可能丢最后一次快照后的数据
- AOF：记录写命令，数据更完整，文件大，恢复慢，可
everysec折中- 混合：AOF 重写时前半 RDB 后半 AOF，兼顾恢复速度与完整性
- 纯缓存场景可关闭持久化；要容灾就开 AOF + 主从/集群
详细解析
RDB（Redis Database）
- 触发：
save阻塞、bgsave子进程、自动save 900 1等规则 - 优点：紧凑、恢复快、对性能影响相对可控（fork 瞬间除外）
- 缺点：两次备份之间宕机会丢数据
AOF（Append Only File）
- 每次写命令追加到文件
appendfsync：always最安全最慢；everysec常用，最多丢 1 秒；no交给 OS- 重写（rewrite）：压缩历史命令，避免 AOF 无限涨
混合持久化（推荐了解）
aof-use-rdb-preamble yes：重写后的 AOF 带 RDB 头，重启先加载 RDB 再重放少量 AOF。
代码与实践
配置片段（示意）
# 以缓存为主、可接受分钟级丢失
save 900 1
save 300 10
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes项目怎么选
| 场景 | 建议 |
|---|---|
| 纯缓存、可回源 DB | 持久化可关或仅 RDB，重点是 主从 + 哨兵/集群 |
| 分布式锁、限流计数 | 丢数据影响大，AOF everysec + 高可用 |
| 会话 token | 丢了用户要重新登录，一般 AOF + 过期时间 |
和业务的边界：核心数据仍以 MySQL 为准，Redis 持久化是为了重启少预热、少击穿，不能替代数据库备份。
写在最后
面试说完 RDB/AOF 后补一句：生产还会做主从复制和监控，持久化只是单机恢复手段之一。
创作不易，转载请注明出处和作者。