Redis 的持久化机制有哪些？
- 标签：后端、Redis
🏛 业务架构师
两种持久化机制对应两种数据丢失容忍度：
- RDB（快照）：周期性把全量数据 fork 子进程写盘（COW 机制）——文件紧凑、恢复快；两次快照之间的数据会丢（默认配置可能丢分钟级）；
- AOF（日志）：每条写命令追加日志——丢失窗口由刷盘策略定：everysec（默认，最多丢 1 秒）/ always（最多丢一条，性能代价大）/ no（跟随系统，不可控）；
- 混合持久化（4.0+，推荐）：AOF 重写时前半段存 RDB 全量 + 后半段增量日志——恢复速度与数据安全的兼顾。
业务配置按数据价值分级（架构核心动作）：
- 纯缓存实例：RDB 甚至关持久化——数据可从 DB 重建，持久化开销（fork 停顿、磁盘 IO）纯属浪费，追性能；
- 计数器/去重标记/会话：AOF everysec——丢 1 秒可接受（计数靠对账校准）；
- 接近"存储"性质的数据（延迟队列、任务状态）：AOF + 混合，甚至 everysec→always 评估——但最终极答案仍是"重要数据别只放 Redis"，DB 才是事实源。
运维视角的两个坑：
- fork 停顿：RDB/AOF 重写都要 fork，内存越大停顿越久（10GB 实例 fork 可达百毫秒级）——大流量时段错峰触发持久化，单实例内存上限控制在 10G 内；
- AOF 膨胀：重写机制压缩，但重写期间双份磁盘占用——磁盘容量预算要留。
一句话：持久化配置是**"数据丢了会怎样"的定价动作**——先分级数据，再配策略，无脑 always 是用全站性能给低价值数据买单。
🏗 系统架构师
Redis 持久化两条路线 RDB 与 AOF（可组合）：
RDB（快照）：
- 机制：
SAVE（阻塞主线程）/BGSAVE（fork 子进程，copy-on-write 写时复制，子进程遍历内存生成压缩二进制快照）； - 优点：文件紧凑、恢复快（直接 load）、对主进程影响小（子进程干活）；
- 缺点：两次快照之间的数据会丢（分钟级窗口）；fork 大内存实例耗时（10GB 实例 fork 可百 ms 级，且 COW 极端时内存翻倍）；
AOF（追加日志）：
- 机制：写命令追加到 aof_buf，按
appendfsync策略刷盘：always（每命令 fsync，最多丢 1 条，性能差）/ everysec（每秒，最多丢 1 秒，推荐）/ no（交 OS，不可控）； - 重写（AOF Rewrite）：fork 子进程按当前数据生成最小命令集，消除文件膨胀；
- 优点：丢失窗口小；缺点：文件大、恢复慢（重放命令）。
4.0+ 混合持久化（我的生产默认）：AOF 重写时，RDB 全量快照做头 + 增量 AOF 追加——恢复速度与数据安全的平衡最优。
实践配置：缓存型实例可只 RDB 甚至关持久化；存储型（分布式锁/队列场景）开混合：aof-use-rdb-preamble yes + everysec；主从 + 哨兵/Cluster 提供高可用层，持久化管单机重启恢复，两者互补不互替。关键认知：Redis 的持久化是"尽力而为"，与 DB 的 ACID 不同级。
💻 全栈开发专家
两种持久化 + 混合模式：
RDB（快照）：
SAVE（阻塞主线程，别用）/BGSAVE（fork 子进程写全量二进制）；- 优点：文件紧凑、恢复快（直接载入）、适合容灾备份；
- 缺点：两次快照间的数据会丢（分钟级）；fork 大内存实例有停顿。
AOF（追加日志）：
- 写命令追加 aof_buf，按
appendfsync策略刷盘：always（每命令，最安全最慢）/everysec（每秒折中，生产默认，最多丢 1 秒）/no（交给 OS）； - 文件大 → AOF 重写（bgrewriteaof，fork 子进程按当前数据生成最小命令集）；
- 7.0 改为 Multi-Part AOF（基础文件 + 增量文件，manifest 管理），重写不再用双写缓冲。
混合持久化（4.0+，我的推荐配置）：
conf
aof-use-rdb-preamble yes重写时基础部分写 RDB 格式（恢复快），增量部分 AOF 格式（丢得少）——恢复速度和数据安全的平衡点。
我的生产配置：appendfsync everysec + 混合开启，RDB 做定时备份（低峰 bgsave 拷走文件）。
必踩的两个坑：
- fork 卡顿：内存越大越明显（页表复制），
info stats看latest_fork_usec；控制单实例 10GB 内、关闭 THP； - 写时复制内存翻倍：bgsave 期间写入越多，COW 复制页越多，内存规划要留余量（maxmemory 别超过物理内存的 50~60%）。