一、备份方式对比
1.1 三种持久化能力
Redis 提供了 RDB、AOF、混合（RDB+AOF）三种持久化方式，它们决定宕机后数据能找回多少：
| 方式 | 机制 | 数据丢失窗口 | 恢复速度 | 文件体积 |
|---|---|---|---|---|
| RDB | 定时快照 | 上次快照至今 | 快 | 小 |
| AOF | 追加命令日志 | 上次 fsync 至今 | 慢 | 大 |
| 混合 | AOF 头用 RDB + 增量 AOF | 极小 | 较快 | 中 |
# 查看当前持久化配置
redis-cli config get save
# 1) "save"
# 2) "3600 1 300 100 60 10000"
redis-cli config get appendonly
# 1) "appendonly"
# 2) "yes"
1.2 容灾的本质
容灾不只是「备份数据」，而是在数据不丢的前提下让服务尽快恢复。备份解决「数据找回」，复制/集群解决「服务可用」，两者组合才是完整容灾。
1.3 备份粒度
| 备份对象 | 粒度 | 典型做法 |
|---|---|---|
| RDB 文件 | 全量快照 | 定时 BGSAVE |
| AOF 文件 | 增量日志 | 持续追加 |
| 从节点 | 冗余副本 | 只读从库 |
| 异地副本 | 跨机房冗余 | 多级复制 |
二、RDB 备份
2.1 RDB 是什么
RDB 是二进制快照，把某个时刻的全部数据序列化到文件。由 save 策略触发，或手动 BGSAVE：
# 手动生成快照（fork 子进程，不阻塞主线程）
BGSAVE
# Background saving started
redis-cli info persistence
# rdb_last_bgsave_status:ok
2.2 RDB 触发策略
# 触发条件：300 秒内 ≥1 次写，或 60 秒内 ≥10000 次写
save 3600 1
save 300 100
save 60 10000
# 关闭 RDB
save ""
# 手动阻塞式快照（不推荐，会阻塞主线程）
SAVE
2.3 RDB 的优缺点
| 优点 | 缺点 |
|---|---|
| 文件小，恢复快 | 数据丢失窗口大（上次快照至今） |
| 子进程生成，不阻塞 | fork 大内存实例耗时且耗内存 |
| 适合定期归档 | 不满足高实时恢复 |
RDB 是「周期性保险」：适合数据丢失容忍度在小时级的场景。绝不能把 RDB 当唯一备份，快照间隔内的写操作在宕机后会全部丢失。
三、AOF 备份
3.1 AOF 是什么
AOF（Append Only File）把每条写命令追加到文件，重启时重放恢复。它记录了每一次修改，数据丢失窗口只取决于 fsync 策略：
# 三种 fsync 策略
appendfsync always # 每条命令都 fsync，最安全但慢
appendfsync everysec # 每秒 fsync，默认，最多丢 1 秒
appendfsync no # 交给操作系统，最多丢数秒
redis-cli config get appendfsync # everysec
3.2 AOF 重写
AOF 随写入无限增长，需要用 BGREWRITEAOF 重写压缩（合并冗余命令、删除过期键）：
BGREWRITEAOF
# Background append only file rewriting started
# 自动重写条件（增长 100% 且 ≥64MB 触发）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 重写原理：读内存数据 → 生成最短命令集 → 替换旧 AOF，期间新写入追加合并
3.3 AOF 的优缺点
| 优点 | 缺点 |
|---|---|
| 数据丢失窗口极小（默认 ≤1s） | 文件大，恢复慢 |
| 可读（文本命令） | 恢复要重放全部命令 |
| 适合高实时恢复 | 高写入下性能开销 |
AOF 是「实时保险」：
everysec是默认平衡点，最多丢 1 秒数据。金融、库存等场景可上always，但要接受写性能下降。
四、混合持久化
4.1 混合 AOF
Redis 4.0+ 支持混合持久化：AOF 重写后，文件头部是 RDB 快照，后续追加增量 AOF 命令。恢复时先加载 RDB（快）再重放少量命令（省）：
aof-use-rdb-preamble yes # 开启混合持久化（默认开启）
# 文件结构: | RDB 快照数据 | 增量 AOF 命令 |...|
# 恢复 = 加载 RDB + 重放 AOF 增量
4.2 三种方式选型
| 场景 | 推荐 | 原因 |
|---|---|---|
| 缓存可重建 | 仅 RDB 或关闭持久化 | 恢复快、开销小 |
| 通用生产 | 混合 AOF | 丢数据少、恢复较快 |
| 强一致数据 | AOF always | 丢数据接近零 |
| 大数据量 | 混合 + 从节点 | 主从配合 |
4.3 配置推荐
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
混合持久化是当前生产主流：RDB 的恢复速度 + AOF 的实时性，两者兼得。开启后 AOF 文件虽大，但重写后头部即 RDB，启动加载大幅加快。
五、手动备份与自动备份策略
5.1 手动备份流程
# 1. 触发快照
redis-cli bgsave
# 2. 找到 RDB 位置并复制到带时间戳的备份目录
redis-cli config get dir # 通常 /var/lib/redis
cp /var/lib/redis/dump.rdb /backup/redis/dump.rdb.$(date +%F)
# 3. 将备份同步到异地存储
rsync -av /backup/redis/ backup-server:/backup/redis/
5.2 自动备份脚本
#!/bin/bash
REDIS_CLI="redis-cli -h 127.0.0.1 -p 6379"
BACKUP_DIR="/backup/redis"
$REDIS_CLI bgsave
sleep 2
cp /var/lib/redis/dump.rdb "$BACKUP_DIR/dump.rdb.$(date +%Y%m%d%H%M)"
find "$BACKUP_DIR" -name "dump.rdb.*" -mtime +30 -delete # 保留 30 天
# crontab 每小时执行
0 * * * * /usr/local/bin/redis_backup.sh >> /var/log/redis_backup.log 2>&1
5.3 备份策略要点
| 要点 | 说明 |
|---|---|
| 频率 | RDB 至少每小时，AOF 每 1 秒 fsync |
| 保留策略 | 按时间多版本，至少保留 30 天 |
| 异地同步 | 备份文件必须离源机房 |
| 定期验证 | 备份能恢复才叫备份 |
| 备份 AOF | 与 RDB 分开，防止单点 |
备份三原则：离源存储、多版本保留、定期恢复演练。只备份不验证，等于没有备份——恢复时才发现文件损坏是最惨的容灾事故。
六、异地容灾架构
6.1 多级复制
通过级联复制把数据扩展到异地机房，形成「主-从-异地从」的多级结构：
# 机房 A（主）→ 机房 A（从）→ 机房 B（从）
# 异地从节点承担跨机房读取，同时作为容灾副本
replicaof 10.0.0.1 6379
6.2 主动-被动与主动-主动
| 架构 | 写能力 | 数据一致性 | 复杂度 |
|---|---|---|---|
| 主动-被动 | 仅主机房 | 主从异步复制 | 低 |
| 主动-主动 | 多机房可写 | 需冲突处理 | 高 |
# 主动-被动：主写异地从只读，主故障后人工/哨兵提升异地从
# 主动-主动：多机房各自主从，通过 CRDT 或业务幂等解决冲突
6.3 容灾层级设计
| 容灾级别 | 手段 | RTO | RPO |
|---|---|---|---|
| 单机 | RDB/AOF | 分钟级 | 秒级 |
| 同城 | 主从 + 哨兵 | 秒级 | 秒级 |
| 异地 | 多级复制 | 分钟级 | 分钟级 |
| 双活 | 主动-主动 | 秒级 | 秒级 |
容灾设计先定 RTO（恢复时间目标）与 RPO（数据丢失容忍），再选架构。异地容灾的成本很高，只有核心业务值得跨机房冗余，一般业务同城主从 + 异地 RDB 备份即可。
七、故障演练流程
7.1 演练目标
故障演练验证的不是「备份存在」，而是「恢复链路可用」：
# 演练项
# 1. 单节点宕机 → 从节点晋升 / 哨兵切换
# 2. 整机房宕机 → 异地备份恢复
# 3. 备份文件损坏 → 校验与降级方案
# 4. 数据误删 → AOF/RDB 时间点恢复
7.2 演练步骤模板
# 1. 计划：定场景、时间窗口、回滚方案
# 2. 演练：真实故障注入（kill 进程、断网、删数据）
# 3. 记录：记录实际 RTO/RPO 与操作步骤
# 4. 复盘：对比目标，修复问题
# 5. 回归：修复后再演练确认
7.3 演练常用命令
# 模拟宕机
redis-cli shutdown nosave
# 模拟数据损坏：清空后用备份恢复
redis-cli flushall
# 模拟进程被杀后自动拉起
systemctl stop redis-server
systemctl start redis-server
演练要点：使用备份文件恢复必须走「完整流程」，包括拷贝、校验、加载、验证数据量一致。脚本化的演练才能发现步骤遗漏，人工演练容易「手顺而漏关键步」。
八、恢复步骤
8.1 RDB 恢复
# 1. 停服并备份当前（可能损坏的）文件
systemctl stop redis-server
mv /var/lib/redis/dump.rdb /var/lib/redis/dump.rdb.bak
# 2. 拷贝备份文件到数据目录并修权限
cp /backup/redis/dump.rdb.20260930 /var/lib/redis/dump.rdb
chown redis:redis /var/lib/redis/dump.rdb
# 3. 启动并验证
systemctl start redis-server
redis-cli dbsize
8.2 AOF 恢复
# AOF 恢复同理：拷贝到 appenddirname 目录
cp /backup/redis/appendonly.aof /var/lib/redis/appendonly.aof
# 尾部损坏时先修复
redis-check-aof --fix appendonly.aof
8.3 恢复后的检查
| 检查项 | 方法 |
|---|---|
| 总 key 数量 | dbsize 对比备份记录 |
| 关键业务 key | 抽样 GET 对比 |
| 数据时效 | 检查是否恢复到预期时间点 |
| 复制状态 | info replication 确认主从 |
| 写入验证 | 恢复后写测试 key 再删除 |
恢复不是「启动成功」就结束：必须对比 key 数量与抽样数据，确认恢复到预期时间点。对一致性要求高的业务，恢复后应做数据完整性核对脚本。
九、备份一致性检查
9.1 备份校验
# RDB 文件完整性检查
redis-check-rdb /backup/redis/dump.rdb.20260930
# [offset ...] \o/ RDB looks OK!
# AOF 文件完整性检查
redis-check-aof /backup/redis/appendonly.aof
9.2 与源数据一致性对比
# 方法：dbsize 对比数量级、抽样对比 value、debug digest 全库摘要（慎用）
redis-cli debug digest
| 检查方式 | 力度 | 成本 |
|---|---|---|
| redis-check-rdb | 文件完整性 | 低 |
| dbsize 对比 | 数量级 | 低 |
| 抽样 value 对比 | 抽样 | 中 |
| debug digest | 全库 | 高，阻塞慎用 |
9.3 持续监控
# 备份任务本身要监控：失败告警、检查文件大小与生成时间
# 每月做一次「备份恢复演练」并记录结果
一致性检查的终极手段是周期性恢复演练：在隔离环境加载备份、对比数据、验证可服务。演练通过，备份才算「有效备份」。
结语
- RDB/AOF/混合三种持久化各有取舍：RDB 快恢复大窗口，AOF 小窗口慢恢复，混合两者兼得，是生产主流。
- RDB 由 save 策略触发 BGSAVE，适合周期归档；快照间隔内的写操作宕机后会丢失。
- AOF 用 appendfsync 控制丢失窗口，everysec 默认最多丢 1 秒，强一致场景可上 always。
- AOF 需要 BGREWRITEAOF 重写控制体积，混合持久化重写后头部即 RDB，启动加载更快。
- 备份策略遵循「离源存储、多版本保留、定期恢复演练」三原则，配合 crontab 自动化。
- 异地容灾按 RTO/RPO 选架构：同城主从哨兵、异地主从复制或主动-主动双活。
- 故障演练要脚本化、走完整恢复流程，记录实际 RTO/RPO 并持续复盘修复。
- 恢复步骤「停服→换文件→启动→验证」五步走，用 redis-check-rdb/aof 校验与抽样对比保证一致性。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。