Redis持久化策略
一句话总结
Redis提供两种持久化策略：RDB和AOF。RDB通过定时生成数据快照实现，适合快速恢复但可能丢失部分数据；AOF记录所有写操作命令，数据完整性更高但文件较大。此外，Redis支持混合持久化模式（AOF+RDB），结合两者优势实现高效备份与恢复。
详细解析
Redis 的持久化机制用于将内存中的数据保存到磁盘，确保在服务器重启后数据不丢失。Redis 提供了两种主要的持久化方式：RDB（快照） 和 AOF（追加日志），以及两者的混合模式。以下是它们的核心原理、优缺点及配置建议：
1. RDB（Redis Database）
原理
定时快照：在指定时间间隔内，将内存中的数据集生成二进制快照（dump.rdb文件）保存到磁盘。
触发方式：
自动触发：通过配置文件设置时间策略（如save 60 10000表示 60 秒内至少 10000 次修改时触发）。
手动触发：执行SAVE（阻塞主线程）或BGSAVE（后台异步生成快照）。
优点
恢复速度快：二进制文件紧凑，加载速度远快于 AOF。
适合备份：RDB 文件是某个时间点的完整数据副本，适合冷备和灾难恢复。
性能影响小：后台异步生成快照，对主线程影响较小。
缺点
数据丢失风险：两次快照之间的数据可能丢失（取决于触发频率）。
大文件生成压力：数据集较大时，BGSAVE的fork操作可能阻塞主线程（内存越大，阻塞时间越长）。
配置示例
redis.conf
save 900 1 # 15 分钟内至少 1 次修改
save 300 10 # 5 分钟内至少 10 次修改
save 60 10000 # 1 分钟内至少 10000 次修改
dbfilename dump.rdb # RDB 文件名
dir ./ # 保存路径
2. AOF（Append Only File）
原理
日志追加：记录每个写操作命令（如SET、DEL）到 AOF 文件，重启时重放命令恢复数据。
同步策略：
appendfsync always：每个命令都同步到磁盘（最安全，性能最低）。
appendfsync everysec：每秒同步一次（默认，平衡安全与性能）。
appendfsync no：由操作系统决定何时同步（最快，数据丢失风险最高）。
优点
数据安全性高：最多丢失 1 秒数据（everysec模式）。
可读性强：AOF 文件为文本格式，便于人工分析或修复。
自动重写优化：通过BGREWRITEAOF压缩冗余命令（如多次SET同一键）。
缺点
文件体积大：AOF 文件通常比 RDB 大，恢复速度慢。
性能开销：高写入负载下，频繁同步可能影响吞吐量。
配置示例
redis.conf
appendonly yes # 启用 AOF
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 的优势，生成一个包含 RDB 数据头和 AOF 增量命令的混合文件。
触发条件：在 AOF 重写时，先以 RDB 格式保存当前数据集，后续增量命令以 AOF 格式追加。
恢复流程：先加载 RDB 快照，再重放后续 AOF 命令。
优点
快速恢复：RDB 提供基础数据，减少恢复时间。
数据完整性：AOF 记录增量操作，降低数据丢失风险。
配置
1
2
redis.conf
aof-use-rdb-preamble yes # 启用混合持久化
4. 持久化方案选择建议
场景 推荐方案 理由
允许分钟级数据丢失 RDB 恢复速度快，适合备份和快速重启。
不允许数据丢失 AOF（appendfsync everysec） 最多丢失 1 秒数据，安全性高。
高吞吐量场景 RDB 或混合持久化 减少 AOF 的同步开销。
数据恢复优先级 混合持久化 兼顾恢复速度和数据完整性。
5. 数据恢复流程
重启 Redis：自动按以下优先级加载持久化文件：
仅 AOF 存在 → 加载 AOF。
仅 RDB 存在 → 加载 RDB。
AOF 和 RDB 均存在 → 加载 AOF（因其记录更完整）。
手动恢复：
将备份的 RDB/AOF 文件放入配置目录，重启 Redis。