Redis 持久化机制详解
Redis 提供三种主要的持久化方式，确保在重启或故障时数据不丢失：
1. RDB（Redis Database） - 快照持久化
核心原理
- 定时生成内存数据的二进制快照
- 将某一时刻的数据集保存到磁盘上的
.rdb文件
触发机制
| 方式 | 命令/配置 | 特点 |
|---|---|---|
| 手动触发 | SAVE |
阻塞式保存，生产环境慎用 |
| 后台触发 | BGSAVE |
创建子进程执行，不阻塞主线程 |
| 自动触发 | 配置文件规则 | 如 save 900 1（15分钟至少1次修改） |
配置示例（redis.conf）
conf复制代码
save 900 1 # 15分钟内至少1个key变化
save 300 10 # 5分钟内至少10个key变化
save 60 10000 # 1分钟内至少10000个key变化
dbfilename dump.rdb # RDB文件名
dir ./ # 保存路径优点
- 紧凑的二进制格式，文件小
- 恢复速度快（适合大规模数据）
- 最大化Redis性能（子进程处理）
缺点
- 可能丢失最后一次快照后的数据
- 大数据量时fork子进程可能阻塞服务
2. AOF（Append Only File） - 日志持久化
核心原理
- 记录所有写操作命令（类似MySQL binlog）
- 命令以Redis协议格式追加到文件末尾
工作流程
同步策略
| 策略 | 命令 | 数据安全 | 性能 |
|---|---|---|---|
| always | appendfsync always |
最高（每条命令同步） | 最低 |
| everysec | appendfsync everysec |
中等（每秒同步） | 平衡（默认） |
| no | appendfsync no |
最低（OS决定） | 最高 |
AOF重写机制
- 解决AOF文件膨胀问题
- 创建当前数据集的最小命令集
- 触发方式：
- 手动：
BGREWRITEAOF - 自动：
auto-aof-rewrite-percentage 100+auto-aof-rewrite-min-size 64mb
- 手动：
配置示例
conf复制代码
appendonly yes # 启用AOF
appendfilename "appendonly.aof"
appendfsync everysec # 推荐配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb优点
- 数据安全更高（最多丢失1秒数据）
- 可读性好（Redis协议文本）
- 意外宕机恢复更可靠
缺点
- 文件体积通常比RDB大
- 恢复速度较慢
- 对性能影响稍高于RDB
3. 混合持久化（Redis 4.0+）
最佳实践方案
- 结合RDB和AOF优势
- 生成包含RDB格式 + 增量AOF命令的文件
工作流程
- 使用
BGSAVE创建RDB快照 - 后续命令写入AOF缓冲区
- 重写时生成
RDB头 + AOF尾的混合文件
配置
conf复制代码
aof-use-rdb-preamble yes # 启用混合模式优势
- 快速加载（RDB部分）
- 数据完整性（AOF部分）
- 文件更紧凑
持久化方案选择指南
| 场景 | 推荐方案 | 说明 |
|---|---|---|
| 数据备份 | RDB | 文件小，恢复快 |
| 高数据安全 | AOF everysec | 最多丢失1秒数据 |
| 生产环境 | 混合持久化 | 最佳平衡方案 |
| 缓存服务 | 关闭持久化 | 纯缓存场景 |
数据恢复优先级
Redis重启时按以下顺序恢复数据：
- 只使用AOF文件（如果启用）
- 使用RDB文件（如果未启用AOF）
- 混合持久化文件（优先加载RDB部分）
运维技巧
-
禁用透明大页 ：防止fork延迟
bash复制代码
echo never > /sys/kernel/mm/transparent_hugepage/enabled -
监控持久化状态 ：
bash复制代码
redis-cli info persistence -
灾难恢复测试：定期验证备份文件有效性
-
多数据中心备份：异地保存RDB/AOF文件
⚠️ 重要提示：持久化不能替代备份！仍需定期将RDB/AOF文件复制到异地安全存储。