Redis 是一款内存型数据库，绝大多数数据都存储在内存中，读写速度极快。但内存数据是易失性的，一旦机器断电、进程崩溃、重启，内存数据会全部丢失。
为了解决数据丢失问题，Redis 提供了持久化机制，把内存数据定期落地到磁盘，保证重启后可以恢复数据。
那么Redis 中一共有三种持久化方案：
RDB 快照持久化：存某一刻的全量数据
AOF 日志持久化：存每一条写命令
混合持久化（RDB+AOF）：兼顾速度与安全，生产最优
一、RDB 持久化（快照）
1.1 原理
RDB（Redis Database）是全量快照。Redis 在指定时间点，把当前内存中所有数据序列化为二进制文件，保存为dump.rdb。简单理解RDB 保存的是“某一瞬间的完整数据镜像”。
1.2 触发方式
有两种触发方式，分别是手动触发和自动触发
手动触发
SAVE：主进程自己做快照，全程阻塞，线上禁用
BGSAVE：fork 子进程做快照，主进程不阻塞，线上默认使用
自动触发（配置文件）
save 900 1 save 300 10 save 60 10000含义：满足任意一条就自动执行 BGSAVE：
900 秒内至少 1 个 key 改动
300 秒内至少 10 个 key 改动
60 秒内至少 10000 个 key 改动
1.3 RDB 优缺点
优点：
二进制压缩文件，体积小，适合备份、迁移
重启恢复数据速度最快
BGSAVE 子进程执行，不阻塞主业务
缺点：
会丢数据：两次快照之间的增量数据宕机丢失
大数据量 fork 会有短暂阻塞
二进制文件无法人工修改、修复
二、AOF 持久化（日志）
2.1 原理
AOF（Append Only File）以日志形式记录每一条写命令，不断追加到 aof 文件末尾。重启 Redis 时，重新执行一遍日志里的命令，恢复内存数据。
AOF 默认关闭，需要手动开启：
appendonly yes2.2 三种刷盘策略 appendfsync
# 每写一条就刷盘，最安全、最慢 appendfsync always # 每秒刷一次盘（默认），最多丢 1 秒数据 appendfsync everysec # 交给系统刷盘，性能最高、最不安全 appendfsync no2.3 AOF 重写机制（bgrewriteaof）
随着不断写入，AOF 文件会越来越大，存在大量冗余命令（多次修改同一个 key）。
AOF 重写：不读旧日志，直接根据当前内存数据，生成最简命令写入新 AOF，替换旧文件，实现文件瘦身。
自动重写配置：
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb2.4 AOF 优缺点
优点：
数据更安全，默认最多丢失 1 秒数据
文本格式，可手动修复损坏日志
缺点：
文件体积比 RDB 大很多
重启恢复速度比 RDB 慢
持续刷盘有一定 IO 压力
三、混合持久化（RDB + AOF）Redis4.0+
现在主要采用两者结合的模式
3.1 作用
结合 RDB恢复快、体积小和 AOF数据安全的优点，解决纯 AOF 重启慢、纯 RDB 丢数据的问题。
开启方式：
aof-use-rdb-preamble yes3.2 机制流程
AOF 重写时，先把当前全量数据以 RDB 二进制格式写入文件头部
后续新的写命令，继续以 AOF 日志追加在后面
最终文件结构：RDB 全量快照 + AOF 增量日志
3.3 重启恢复
先快速加载头部 RDB 全量数据，再回放后面少量 AOF 增量命令，又快又安全。
四、Redis 数据恢复优先级
开启 AOF/混合持久化：优先加载 AOF 文件
未开启 AOF：加载 RDB 文件
AOF 损坏可修复：
redis-check-aof --fix xxx.aof
五、生产环境最佳实践
不单独使用 RDB：丢数据风险高
生产推荐开启：AOF + 混合持久化
RDB 可作为定时冷备份，用于异地容灾
持久化文件与业务磁盘分离，防止磁盘故障数据丢失
大内存机器控制重写频率，避免频繁 fork 导致卡顿
总结
RDB：快照、体积小、恢复快、会丢数据 → 适合备份
AOF：日志、安全性高、文件大、恢复慢 → 适合保数据
混合持久化：集两者优点，生产环境标准方案
