Redis持久化机制：AOF与RDB深度解析
一、RDB持久化机制
1. RDB核心原理
RDB（Redis Database）是Redis的快照式持久化方式，通过生成数据集的二进制快照文件（dump.rdb）实现持久化。
核心特性：
二进制压缩存储：紧凑的单文件格式
全量备份：保存某个时间点的完整数据状态
Fork子进程：通过写时复制（COW）机制保证主进程不阻塞
2. RDB触发方式
手动触发：
# 同步保存（阻塞主进程）redis-cli SAVE# 异步保存（非阻塞）redis-cli BGSAVE自动触发（配置redis.conf）：
save 900 1 # 900秒内至少1个key变化save 300 10 # 300秒内至少10个key变化save 60 10000 # 60秒内至少10000个key变化3. RDB优缺点分析
优势：
恢复速度快（直接加载二进制文件）
文件体积小（二进制压缩格式）
适合灾难恢复（完整数据备份）
劣势：
数据安全性低（可能丢失最后一次快照后的数据）
Fork操作可能阻塞主进程（大数据集时）
二、AOF持久化机制
1. AOF核心原理
AOF（Append Only File）以日志形式记录每个写操作，通过重放命令恢复数据。
核心特性：
命令追加：以Redis协议格式记录写操作
文件重写：压缩冗余命令（BGREWRITEAOF）
三种同步策略：always/everysec/no
2. AOF工作流程
[Redis Client] -- 写命令 --> [AOF Buffer] -- 同步策略 --> [AOF文件]3. AOF配置详解（redis.conf）
appendonly yes # 启用AOFappendfilename "appendonly.aof" # 文件名appendfsync everysec # 同步策略auto-aof-rewrite-percentage 100 # 文件增长比例阈值auto-aof-rewrite-min-size 64mb # 重写最小文件大小4. AOF重写机制
重写过程：
1. Fork子进程扫描数据库生成新AOF
2. 期间新命令写入AOF缓冲区和重写缓冲区
3. 重写完成后追加缓冲区的命令
4. 原子替换旧AOF文件
5. AOF优缺点分析
优势：
数据安全性高（最多丢失1秒数据）
可读性强（文本协议格式）
自动修复机制（redis-check-aof工具）
劣势：
文件体积大（存储所有写命令）
恢复速度慢（需要重放命令）
性能开销大（always模式）
三、RDB与AOF对比
| 维度 | RDB | AOF |
| 持久化方式 | 快照 | 命令日志 |
| 数据安全性 | 可能丢失分钟级数据 | 最多丢失1秒数据 |
| 文件体积 | 小（二进制压缩） | 大（文本命令） |
| 恢复速度 | 快 | 慢 |
| 性能影响 | Fork时内存压力大 | 持续写入开销 |
| 适用场景 | 灾难恢复、快速重启 | 数据安全要求高 |
四、常见问题解答
1：AOF文件过大如何处理？
解决方案：
1. 手动执行BGREWRITEAOF
2. 调整自动重写配置：
auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb3. 临时切换为RDB持久化（需权衡数据安全性）
2：RDB持久化期间服务是否可用？
答案：
SAVE命令：完全阻塞，服务不可用
BGSAVE命令：主进程继续服务（Fork时有短暂阻塞）
建议在从节点执行持久化操作
3：如何选择持久化方式？
1. 能容忍分钟级数据丢失 → RDB
2. 要求秒级数据安全 → AOF
3. Redis 4.0+环境 → 混合模式（推荐）
4. 极高性能要求 → 关闭持久化（风险自担）