Redis持久化机制：RDB与AOF实战解析与优化

1. Redis持久化机制概述

Redis作为内存数据库的标杆产品，其持久化能力直接决定了数据可靠性等级。我在生产环境维护过多个TB级Redis集群，深刻体会到持久化配置不当引发的数据灾难。Redis提供了两种互补的持久化方案：AOF（Append Only File）和RDB（Redis Database）。前者记录所有写操作命令，后者生成内存快照，二者配合使用才能构建完整的数据安全体系。

关键认知误区：很多开发者认为开启持久化就万事大吉，实际上不同配置组合下的数据丢失风险差异巨大。我曾遇到过AOF每秒刷盘（appendfsync everysec）配置下，服务器异常断电导致最后1秒数据丢失的案例，这对金融场景是不可接受的。

2. RDB持久化深度解析

2.1 RDB工作原理

RDB通过fork子进程生成内存快照文件（默认dump.rdb）。当执行SAVE或BGSAVE命令时：

1. 主进程fork出子进程（COPY-ON-WRITE机制）
2. 子进程遍历内存数据库生成二进制快照
3. 临时文件生成后原子替换旧文件

bash复制# 手动触发RDB快照
redis-cli SAVE       # 阻塞式
redis-cli BGSAVE     # 后台异步

2.2 配置参数精要

在redis.conf中关键参数：

conf复制save 900 1       # 15分钟至少1个key变化
save 300 10      # 5分钟至少10个key变化 
save 60 10000    # 1分钟至少10000个key变化
stop-writes-on-bgsave-error yes  # 磁盘满时停止写入
rdbcompression yes               # 启用LZF压缩

血泪教训：stop-writes-on-bgsave-error一定要设为yes！曾经有集群因磁盘满导致bgsave失败，但继续接收写入请求，最终导致数据全部丢失。

2.3 RDB的优劣分析

优势：

• 二进制紧凑格式，恢复速度极快（比AOF快10倍以上）
• 适合冷备和灾难恢复
• 对性能影响较小（子进程处理）

劣势：

• 默认配置下可能丢失分钟级数据
• 大数据量时fork可能