Redis持久化机制详解：RDB、AOF与混合模式

Redis作为内存数据库，持久化是其保证数据安全的关键机制。本文将深入解析Redis的三种持久化方式：RDB快照、AOF日志以及混合持久化模式，帮助您根据业务场景选择合适的策略。

1. RDB(快照)持久化

核心原理

RDB(Redis Database)通过创建内存数据的二进制快照实现持久化。快照文件是经过压缩的二进制文件，默认保存为dump.rdb。

触发方式

• 手动触发：执行SAVE(阻塞)或BGSAVE(后台异步)命令

• 自动触发：配置save <seconds> <changes>规则

  save 900 1    # 900秒内至少1次修改
  save 300 10   # 300秒内至少10次修改
  save 60 10000 # 60秒内至少10000次修改

优势与局限

优势：

• 二进制压缩格式，文件体积小
• 恢复速度快，适合大规模数据
• 对性能影响小（子进程处理）

局限：

• 可能丢失最后一次快照后的数据
• 大数据量时fork操作可能阻塞主线程

实践建议

// Java示例：通过Jedis触发RDB保存
Jedis jedis = new Jedis("localhost");
// 异步保存
jedis.bgsave();
// 阻塞式保存（生产环境慎用）
// jedis.save();

配置要点：生产环境建议关闭SAVE命令，仅使用BGSAVE。对于8GB以上内存实例，需监控fork耗时。

2. AOF(追加文件)持久化

核心原理

AOF(Append Only File)记录每个写操作命令，以Redis协议格式追加到文件末尾。重启时重新执行这些命令恢复数据。

同步策略

AOF重写机制

解决文件膨胀问题，通过创建新AOF文件替换旧文件：

1. 读取当前数据库状态
2. 用最简命令序列重建数据
3. 写入临时文件后原子替换

触发方式：

• 手动：BGREWRITEAOF
• 自动：配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size

实践建议

# redis.conf关键配置
appendonly yes
appendfilename "appendonly.aof"
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

注意：AOF文件可能比RDB大很多，但数据安全性更高。建议SSD磁盘部署。

3. 混合持久化（Redis 4.0+）

工作原理

混合模式结合RDB和AOF优势：

1. 定期执行RDB快照
2. 两次快照间的增量数据用AOF记录
3. 重启时先加载RDB，再重放AOF

配置方法

aof-use-rdb-preamble yes  # 启用混合模式

优势体现

• 恢复速度比纯AOF快
• 数据安全性比纯RDB高
• 文件体积比纯AOF小

对比总结

生产环境建议

1. 数据安全优先：使用appendfsync everysec的AOF+混合模式
2. 性能优先：RDB为主，适当缩短保存间隔

3. 监控指标：

   redis-cli info persistence
   # 关注：
   # rdb_last_bgsave_status
   # aof_last_bgrewrite_status
   # aof_current_size

4. 灾难恢复：定期将RDB/AOF文件备份到异地存储

通过合理配置持久化策略，可以在性能和数据安全间取得平衡，满足不同业务场景需求。