RDB 快照策略设计与业务错峰

save 参数抄默认值人人会做，难的是让它匹配业务的写入节奏与可容忍的数据丢失量。本文给出从 RPO 目标反推快照条件的方法，以及错峰、定时快照的落地配置。

一、save 条件的真实语义

save 3600 1 300 100 60 10000

每条规则的含义：距上次成功快照超过 m 秒，且期间累计至少 n 次修改，就触发一次 BGSAVE。多个条件是"或"的关系，任一满足即触发；save "" 关闭全部自动快照。

实现上，Redis 在 serverCron（每 100 ms 执行一次）里检查 dirty 计数与 dirty 时间：每条修改命令让 dirty 加 1，条件命中就发起 BGSAVE。理解这一点就能推断行为：写入高峰期，"60 秒 10000 次修改"的条件会反复命中，快照可能接连不断，fork 与 COW 的成本随之叠加。

有两个细节经常被误解。第一，save 参数用的是"距上次成功快照的秒数"和"期间的 dirty 累计量"，一旦 BGSAVE 成功就把 dirty 清零、计时重置，所以它是"节流后触发"，不是"定期触发"——写入量波动大时，实际快照间隔并不均匀。第二，条件里写的是"秒数 + 修改次数"，判断时需要两个条件同时成立，这与"多条件之间是或"并不矛盾：单个条件内部是"且"，条件之间是"或"。

dirty 计数的粒度是命令而非 key。一条 MSET 写入 100 个 key 只让 dirty 加 1，一个 DEL 删除大 key 也只加 1。这带来一个偏差：批量导入场景下，dirty 增长远小于实际数据变化量，按 dirty 触发的快照可能迟迟不来。RDB 快照的价值在于覆盖"数据变成什么样"，而不在于"改了多少次"，所以对批量写入为主的实例，应当更多依赖定时快照而不是 dirty 条件。

二、从 RPO 反推快照频率

RPO（恢复点目标）是灾难发生时最多可接受丢失的数据时长。设计步骤：

1. 与业务确认可容忍丢失量，例如"最多丢 5 分钟的非关键数据"；
2. 若同时开启 AOF everysec，RPO 由 AOF 兜底，RDB 只是补充冷备，快照条件可以很松；
3. 若是纯 RDB 实例，快照间隔就是 RPO 上限，条件必须收紧，同时评估 fork 与 COW 的代价是否可承受。

三种典型模板：

# 纯缓存，重启后可回源，只做兜底冷备
save 3600 1

# 一般业务，RDB 为主，RPO 目标控制在分钟级
save 300 100 60 1000

# 关键数据，安全交给 AOF，RDB 仅作备份基线
save 3600 1
appendonly yes
appendfsync everysec

三、业务错峰设计

快照成本与写入速率正相关：COW 放大近似等于快照期间被写的页数，fork 停顿固定但影响在高峰期被放大。错峰的做法：

• 识别写入高峰：用 INFO commandstats 或业务埋点确认峰值时段，例如电商晚 8 点、跑批任务整点；
• 条件按写入画像整体放宽：save 条件不区分时段，但可以用更高的 n 门槛减少高峰期触发；
• 峰谷动态调整：写入模式可预期时，用 CONFIG SET save "" 在高峰临时关闭自动快照，峰后恢复，属于进阶用法；
• 定时手动快照补位：低峰期用 crontab 强制 BGSAVE，保证冷备节奏。

#!/bin/bash
# snapshot.sh：凌晨强制快照，完成后打包并校验
set -e
redis-cli BGSAVE
sleep 2   # 等待状态翻转
while [ "$(redis-cli INFO persistence | grep rdb_bgsave_in_progress | tr -d '\r' | cut -d: -f2)" = "1" ]; do
  sleep 5
done
tar czf /backup/rdb-$(date +%F).tgz -C /var/lib/redis dump.rdb
md5sum /backup/rdb-$(date +%F).tgz > /backup/rdb-$(date +%F).tgz.md5

crontab 挂在每天 03:00，配合 rsync 或对象存储客户端把压缩包外传到异机。

四、验证策略是否按预期工作

参数改完不等于行为正确，需要从两个方向验证。第一是看实际触发节奏，INFO persistence 里的时间戳字段能直接读出：

redis-cli INFO persistence | grep -E "rdb_last_save_time|rdb_changes_since_last_save|rdb_bgsave_in_progress"
# rdb_last_save_time:1761350402
# rdb_changes_since_last_save:1349
# rdb_bgsave_in_progress:0

rdb_last_save_time 是上次成功快照的 Unix 时间戳，与当前时间相减得到实际间隔；rdb_changes_since_last_save 就是 dirty 计数，可以拿来对照 save 条件里的 n。把这两个值与配置并排看，能立刻判断"条件设太松导致几乎不触发"还是"设太紧导致高频触发"。注意 rdb_last_save_time 在实例刚启动、尚未快照时会等于启动时间，不要误读为"刚做过快照"。

第二是看快照耗时与频率的长期趋势。rdb_last_bgsave_time_sec 记录上次耗时，若它在数周内持续上升，说明数据量增长让快照窗口变长，COW 风险同步上升，此时应重新评估单实例大小而不是继续加大磁盘。

提示：如果 rdb_changes_since_last_save 长期为 0 而业务明明有写入，检查是否误配了 save ""，或者写入全部打到了从库（从库默认 replica-read-only yes 会直接拒绝）。

五、配套检查项

• stop-writes-on-bgsave-error yes：快照失败即拒绝写入，防止"以为有持久化"；配套磁盘告警才有意义。
• 磁盘余量：按数据量加至少一倍预留，RDB 临时文件与压缩包可能并存。
• 备份校验：打包后跑 redis-check-rdb 并记 md5，让每一份备份处于"随时可用"状态。
• 恢复演练：每季度用真实备份文件在隔离环境跑一遍恢复流程，实测 RTO。

这四项里最容易流于形式的是后两项。备份校验如果只做 md5sum 比对，验证的只是"文件传输没出错"，而不是"文件能被 Redis 解析"，必须真正跑一次 redis-check-rdb。恢复演练同理，只看备份文件存在、大小合理，与实际用 --dir 指向备份目录启动一个新实例相比，差别可能是一次 CRC 报错、一次版本不兼容、一次权限配置遗漏。演练的价值就在于把这些小问题提前暴露在测试环境。

常见坑 / 最佳实践

1. 默认三条件直接上生产。 "60 秒 10000 次"在中等写入量实例上就是高频快照，先按写入画像重算再上线。
2. 定时快照没有等待完成就打包。 BGSAVE 是异步的，脚本必须轮询 rdb_bgsave_in_progress，否则打包到的是上一代旧文件。
3. 把 save 条件当作精确的 RPO 保证。 条件是"达到才触发"，极端情况下两次快照间隔可以远超预期，纯 RDB 的 RPO 要按更坏情况评估。
4. 高峰期手动 BGSAVE 做应急备份。 高峰期 fork 停顿与 COW 都被放大，应急需求优先在从库执行。
5. 快照策略从不复查。 业务写入量翻倍后旧策略可能失效，把 save 参数评审纳入容量复盘。

小结

• save 条件的语义是"m 秒内至少 n 次修改"，多条件之间是或关系，由 serverCron 周期检查。
• 快照频率从 RPO 反推：有 AOF 兜底可以放松，纯 RDB 必须收紧并评估代价。
• 错峰的核心是把快照成本挪出写入高峰：识别峰值、放宽条件、低峰定时补位。
• 定时快照脚本要轮询完成状态再打包，并做校验与外传。
• stop-writes-on-bgsave-error、磁盘告警与季度恢复演练是策略落地的三件配套。