一句话总结
RDB是定时快照，文件紧凑恢复快但可能丢数据；AOF是追加日志，数据安全但文件大恢复慢。生产建议两者结合使用，Redis 4.0+支持混合持久化。
初级理解
RDB（快照）：
• 原理：按时间间隔生成数据快照（fork子进程，COW机制）
• 优点：文件紧凑、恢复速度极快
• 缺点：两次快照之间的数据可能丢失
AOF（追加日志）：
• 原理：记录每一次写命令
• 优点：数据安全性高（支持秒级或每次写入同步）
• 缺点：文件体积大、恢复速度慢
一句话总结：RDB快但可能丢数据，AOF安全但文件大。
中级深入
AOF重写机制：
• 当AOF文件增长到一定大小时，触发重写
• 重写过程：fork子进程，根据当前内存数据生成新AOF，替代旧文件
• 优点：压缩AOF文件体积，加快恢复速度
混合持久化（Redis 4.0+）：
• AOF重写时，前半部分写RDB格式，后半部分写AOF格式
• 兼顾了RDB的快速加载和AOF的数据安全性
• 推荐生产环境使用
注意：AOF重写期间，新的写命令会同时写入旧AOF和重写缓冲区，保证数据不丢失。
高级拓展
生产环境最佳实践：
# 同时开启RDB和AOF
appendonly yes
appendfsync everysec # 每秒同步，兼顾安全和性能
# RDB配置
save 900 1 # 900秒内至少1次修改
save 300 10 # 300秒内至少10次修改
save 60 10000 # 60秒内至少10000次修改
Fork性能问题：
• RDB和AOF重写都需要fork子进程
• fork采用COW（Copy-On-Write）机制，子进程共享父进程内存页
• 大内存实例fork耗时较长，可能导致短暂卡顿
• 建议：控制Redis实例内存大小，或使用Linux大页优化
面试加分项：能说出混合持久化、AOF重写机制、Fork的COW原理，说明你对Redis持久化有深入理解。
实战场景
场景：数据安全与恢复速度的平衡
# 方案：开启混合持久化
appendonly yes
aof-use-rdb-preamble yes # Redis 4.0+混合持久化
# 效果：
# 1. AOF文件前半部分是RDB格式（快速加载）
# 2. 后半部分是AOF格式（增量数据）
# 3. 兼顾恢复速度和数据安全
场景：Fork卡顿优化
# 问题：Redis内存20GB，fork耗时约2秒
# 解决方案：
# 1. 控制单实例内存（建议<10GB）
# 2. 使用主从架构，从节点做持久化
# 3. Linux配置：echo never > /sys/kernel/mm/transparent_hugepage/enabled
面试模拟
Q：RDB和AOF如何选择？
A：推荐两者结合使用。以AOF为主保证数据安全性（everysec策略），以RDB为辅用于快速恢复和冷备。Redis 4.0+的混合持久化是最佳方案，兼顾了RDB的快速加载和AOF的数据安全。
Q：Redis持久化时fork为什么会导致卡顿？
A：fork采用COW（Copy-On-Write）机制，虽然不会立即复制内存，但在fork过程中需要遍历页表，对于大内存实例（如20GB），这个过程可能耗时1-2秒。期间Redis主线程被阻塞，导致卡顿。优化方案包括控制实例内存大小、使用大页、主从分离等。