一句话
Redis 数据在内存里，断电就丢。RDB 是定期拍快照（恢复快但可能丢数据），AOF 是记录每条写命令（数据安全但文件大恢复慢）。生产推荐 RDB + AOF 混合持久化。
1. 为什么需要持久化？
text
Redis 是内存数据库 → 断电/宕机 → 数据全丢
持久化的目标：把内存数据写到磁盘，宕机后能恢复2. RDB（快照）
原理
text
在指定时间间隔内，fork 一个子进程，把内存中的数据集以二进制形式写入 dump.rdb 文件触发条件
text
① 自动触发：配置 save 规则
save 900 1 → 900秒内至少1次修改就触发
save 300 10 → 300秒内至少10次修改就触发
save 60 10000 → 60秒内至少10000次修改就触发
② 手动触发：
SAVE → 阻塞主线程，不推荐
BGSAVE → fork 子进程，不阻塞（推荐）优点与缺点
text
优点：
✅ 文件紧凑，体积小
✅ 恢复速度快（直接加载二进制文件）
✅ 适合备份和灾难恢复
缺点：
❌ 不是实时的，两次快照之间的数据会丢失
❌ fork 子进程时如果数据量大，可能短暂卡顿3. AOF（追加文件）
原理
text
以日志形式记录服务器收到的每一条写命令
重启时通过重放（replay）这些命令来重建数据AOF 的三种同步策略
| 策略 | 说明 | 数据安全 | 性能 |
|---|---|---|---|
always |
每条写命令都 fsync | 最好，最多丢一条 | 最差 |
everysec |
每秒 fsync 一次（推荐） | 最多丢 1 秒数据 | 折中 |
no |
由操作系统决定何时 fsync | 可能丢较多数据 | 最好 |
AOF 重写（AOF Rewrite）
text
AOF 文件会越来越大（因为记录了所有写命令）
Redis 会定期对 AOF 文件进行"瘦身"------重写
重写不是读取旧 AOF 文件，而是直接读取当前内存数据
用最少的命令重新生成一个新的 AOF 文件
触发：
① 自动：配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size
② 手动：BGREWRITEAOF优点与缺点
text
优点：
✅ 数据安全性更高（everysec 最多丢 1 秒）
✅ 日志文件可读，即使损坏也能部分恢复
✅ 兼容旧版本数据格式
缺点：
❌ 文件比 RDB 大
❌ 恢复速度慢（要逐条重放命令）
❌ everysec 模式下 fsync 会影响性能4. RDB vs AOF 对比
| 对比维度 | RDB | AOF |
|---|---|---|
| 数据安全 | 可能丢数分钟数据 | 最多丢 1 秒（everysec） |
| 文件大小 | 小（二进制压缩） | 大（记录所有写命令） |
| 恢复速度 | 快（直接加载） | 慢（逐条重放） |
| 对性能影响 | fork 时可能有短暂卡顿 | everysec 模式下有 fsync 开销 |
| 适合场景 | 备份、灾难恢复、数据容忍度高 | 数据安全要求高 |
5. 混合持久化（推荐）
Redis 4.0 引入，结合两者优势：
text
aof-use-rdb-preamble yes
AOF 文件结构：
前半部分 → RDB 格式的全量快照（恢复快）
后半部分 → 增量的 AOF 写命令（数据安全）
重启时：
先快速加载 RDB 部分 → 再重放少量 AOF 命令
→ 既快又安全 ✅6. 生产建议
text
纯缓存场景（丢数据无所谓）：
→ 可以关闭持久化，或者只开 RDB 做备份
数据存储场景（不能丢数据）：
→ RDB + AOF 混合持久化（推荐）
→ AOF 用 everysec 策略
注意：持久化只保单机数据安全
磁盘坏了照样丢数据 → 还需要主从复制/集群🎙 面试回答模板
text
"Redis 持久化有两种方式：RDB 和 AOF。RDB 是定期对内存数据拍快照，
生成 dump.rdb 二进制文件，优点是文件小恢复快，缺点是两次快照之间的数据
可能丢失。AOF 是以日志形式记录每一条写命令，重启时通过重放命令重建数据，
优点是数据安全性高，everysec 模式最多丢 1 秒，缺点是文件大恢复慢。
生产环境推荐用 Redis 4.0 的混合持久化，AOF 文件前半部分是 RDB 格式的
全量快照，后半部分是增量的 AOF 命令，重启时先快速加载 RDB 部分再重放
少量命令，既恢复快又保证数据安全。"参考来源
01_Raw【原始素材】/notion 资料/Notion/任务/Redis进阶二之Redis数据安全性分析.md- Redis 官方文档：Persistence