Redis的持久化有哪几种方式？

1. RDB（Redis Database）—— 快照式持久化

原理：

在指定时间间隔内，将内存中的数据生成二进制快照文件（默认保存为dump.rdb）。
触发方式支持手动触发（SAVE/BGSAVE）和自动触发（配置save <seconds> <changes>）。

核心特点：

优点：
- 文件紧凑（二进制压缩），适合备份与全量恢复。
- 数据恢复速度快（直接加载到内存）。
- 对性能影响小（子进程后台生成快照，主进程继续服务）。
缺点：
- 可能丢失最后一次快照后的数据（取决于备份周期）。
- 数据量大时，生成快照可能导致瞬时延迟。

测试场景建议：

验证BGSAVE期间主进程的可用性（如持续写入是否正常）。
模拟宕机后从RDB文件恢复的数据完整性（是否符合最后一次快照时间点）。
监控fork子进程时的内存开销（尤其在数据量大的情况下）。

配置示例：

bash

复制

# 900秒内至少1次修改触发快照  
save 900 1  
# 300秒内至少10次修改触发快照  
save 300 10

2. AOF（Append Only File）—— 日志式持久化

原理：

记录所有写操作命令（以文本追加方式写入AOF文件）。
支持三种同步策略：
- appendfsync always：每次写操作都同步（数据最安全，性能最低）。
- appendfsync everysec：每秒同步一次（平衡性能与安全，默认配置）。
- appendfsync no：由操作系统决定同步时机（性能最高，数据风险最大）。

核心特点：

优点：
- 数据丢失风险低（取决于同步策略）。
- AOF文件可读性强（便于人工分析或修复）。
- 支持重写机制（BGREWRITEAOF压缩冗余命令）。
缺点：
- 文件体积通常比RDB大。
- 数据恢复速度较慢（需回放所有命令）。
- 高并发下可能因AOF追加写入影响吞吐量。

测试场景建议：

测试不同appendfsync策略下的性能差异（TPS/QPS对比）。
模拟AOF文件损坏（如手动删除部分内容）后的修复能力（使用redis-check-aof工具）。
验证AOF重写期间对系统资源（CPU/内存）的占用情况。

配置示例：

bash

复制

appendonly yes  
appendfilename "appendonly.aof"  
appendfsync everysec  
auto-aof-rewrite-percentage 100  # AOF文件增长100%时触发重写  
auto-aof-rewrite-min-size 64mb   # AOF文件最小重写大小

3. 混合持久化（RDB+AOF）—— Redis 4.0+ 的优化方案

原理：

结合RDB和AOF的优点，在AOF重写时，先将当前数据以RDB格式写入AOF文件头部，后续增量命令以AOF格式追加。
文件内容示例：

复制
```
[RDB二进制数据][AOF追加命令]  
```

核心特点：

优点：
- 快速加载RDB部分数据，减少恢复时间。
- 保留AOF的增量命令，降低数据丢失风险。
缺点：
- 仅Redis 4.0以上版本支持。
- 文件结构复杂，需兼容性保障。

测试场景建议：

验证混合持久化文件的兼容性（版本升级/降级场景）。
对比纯AOF与混合持久化的恢复速度差异。
检查RDB与AOF部分的数据一致性。

配置示例：

bash

复制

aof-use-rdb-preamble yes  # 开启混合持久化

4. 持久化方案选型与测试关注点

如何选择？

场景	推荐方案
允许分钟级数据丢失	RDB
要求数据高可靠	AOF（everysec策略）
需快速恢复且容灾严格	混合持久化

测试工程师的思考维度：

故障恢复验证：
- 强制杀死Redis进程后，检查持久化文件是否完整。
- 模拟磁盘写满场景，观察持久化失败时的告警与处理机制。
性能压测：
- 对比开启/关闭持久化时的吞吐量差异（尤其是AOF的always模式）。
- 监控持久化过程中的内存复制（Copy-On-Write）开销。
数据一致性：
- 在持久化切换过程中（如RDB转AOF），验证数据无丢失或重复。
- 测试主从复制与持久化的协同机制（如主节点持久化失败对从节点的影响）。