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

1. Redis持久化机制的必要性

在分布式系统架构中，Redis作为内存数据库的标杆产品，其性能优势主要源于数据全内存操作的特性。但这也带来了一个关键问题：当服务器意外宕机或进程崩溃时，内存中的数据会瞬间消失。2017年某电商平台就曾因未正确配置持久化，导致促销活动期间缓存雪崩，直接损失超过3000万订单。

提示：内存数据库的"快"是以数据易失性为代价的，持久化机制就是解决这个核心矛盾的钥匙。

Redis提供了两种互补的持久化方案：

• RDB（Redis Database）：定时生成内存快照
• AOF（Append Only File）：记录所有写操作命令

这两种方式就像摄影中的"全景照片"和"连续录像"——RDB捕捉某个瞬间的完整状态，而AOF则记录导致状态变化的所有动作。实际生产环境中，我们通常会同时启用两种方式，就像既定期备份完整数据库，又保留所有操作日志。

2. RDB持久化深度解析

2.1 RDB的工作原理

RDB的核心原理是通过fork子进程来完成内存快照的生成。当触发保存条件时，Redis主进程会创建一个完全相同的子进程，这个子进程拥有与父进程完全相同的内存数据视图。子进程将内存数据序列化写入临时RDB文件，完成后替换旧文件。

这个设计有三大精妙之处：

1. 主进程继续服务客户端请求，只有fork时有短暂阻塞
2. 子进程写入临时文件避免损坏现有备份
3. 采用二进制压缩格式，文件体积通常只有内存数据的1/10

bash复制# 查看当前RDB配置
redis-cli config get save

2.2 RDB的配置策略

默认配置下，Redis会在以下条件满足时触发BGSAVE：

code复制save 900 1     # 900秒(15分钟)内至少1个key变化
save 300 10    # 300秒(5分钟)内至少10个key变化  
save 60 10000  # 60秒内至少10000个key变化

对于电商类应用，我建议调整为：

code复制save 300 100   # 5分钟100次写入
save 60 1000   # 1分钟1000次写入

注意：save "" 会完全禁用RDB，这在生产环境是极其危险的配置

2.3 RDB的优劣