把重活放到低谷
把快照与重写安排在业务低峰，是成本最低也最有效的一项优化：写命令少意味着写时复制产生的额外内存更少、磁盘同步竞争更弱、子进程更快结束，主进程被打断的概率也更低。做法是用调度工具在低谷窗口显式触发一次快照或重写，并在触发之后校验结果，避免出现任务显示成功、快照其实失败的假成功。
基本信息
| 时机 | 业务低谷或既定维护窗口 |
|---|---|
| 方式 | 通过调度工具显式触发快照或重写 |
| 校验 | 核对最近保存时间与保存状态字段 |
| 错峰要求 | 多实例与多节点不要同一时刻执行 |
| 选窗口依据 | 以实际监控曲线为准，而非凭经验判断 |
典型使用场景
- 核心实例的自动快照策略与业务低谷对齐，减少对在线请求的影响
- 大实例升级或迁移前，在低峰手工触发一次全量快照作为基线备份
- 多分片集群错峰编排备份，避免同时抢占存储带宽
- 重写频繁的实例把重写安排在低谷，缓解切换瞬间的卡顿
- 复盘时确认快照窗口是否真的落在业务低谷，而非名义上的夜间
低峰触发与校验
低峰触发与校验
redis-cli BGSAVE # 低峰手工触发一次快照
redis-cli LASTSAVE # 取最近一次成功保存的时间戳
redis-cli INFO persistence | grep rdb_last_bgsave_status # 确认保存结果状态
date -d @$(redis-cli LASTSAVE) # 把时间戳换算成可读时间核对
redis-cli BGREWRITEAOF # 需要时同步安排一次重写编排检查项
| 检查项 | 正确做法 | 做错的风险 |
|---|---|---|
| 窗口选择 | 按实际监控曲线选低谷 | 名义夜间但仍是高峰，影响放大 |
| 多实例错峰 | 按机器与存储分组错开 | 同时写盘，存储带宽被打满 |
| 结果校验 | 核对状态字段与时间戳 | 假成功，以为有备份实际没有 |
| 任务告警 | 失败时通知值班 | 连续失败无人知晓，备份长期缺失 |
自动化脚本触发之后一定要校验结果，只看命令是否返回成功是不够的，后台保存失败不会让触发命令本身报错。
所谓低峰要以监控数据为准：大促期间的夜间可能仍然高于日常白天峰值，覆盖率高的监控才能支撑这个判断。