Redis RDB触发完全依赖写操作而非定时任务，需通过预判写入节奏、禁用自动save并用cron+BGSAVE精确调度；必须检查LASTSAVE和dump.rdb文件有效性，混用AOF时RDB仅作冷备。
Redis RDB触发时机由save指令控制，不是定时任务
很多人误以为save配置像cron一样按固定时间跑，其实它完全依赖写操作触发：只要在指定时间内满足“键变更次数 ≥ 阈值”，就立刻fork子进程执行RDB。这意味着高峰写入期反而最容易意外触发，而你想避开的时段可能根本没写入、压根不触发。
所以真正可控的只有两个动作：提前预判写入节奏、手动干预触发时机。
- 用
INFO commandstats或redis-cli --stat持续观察cmdstat_set/cmdstat_hset等写命令QPS趋势，找出稳定低谷（比如凌晨2–4点） - 确认业务低峰后，再用
CONFIG SET save "900 1 300 10"收紧阈值——让RDB只在极低写入量下才可能自动触发 - 禁用所有自动save（设为
save ""），改用redis-cli -a在运维脚本中精确调度BGSAVE
用Linux cron + redis-cli组合实现“绝对准时”的低峰RDB
这是生产中最稳妥的做法：把RDB完全交给外部调度，和Redis自身save逻辑解耦。注意必须用BGSAVE而非SAVE，否则会阻塞主线程。
示例crontab（每天凌晨3:15触发）：
15 3 * * * /usr/bin/redis-cli -h 127.0.0.1 -p 6379 -a 'yourpass' BGSAVE > /dev/null 2>&1
- 务必加
-h和-p参数，避免连接默认localhost:6379导致跨实例误操作 - 密码含特殊字符时，用单引号包裹
-a参数值，否则shell可能解析失败 - 建议在
BGSAVE前加redis-cli ping健康检查，失败则跳过，防止主从切换期间连到从库 - 输出重定向到
/dev/null，避免crond邮件告警干扰
警惕BGSAVE失败但无报错的静默场景
BGSAVE命令返回OK只代表子进程已启动，不代表RDB文件生成成功。磁盘满、权限不足、父进程OOM killer杀掉子进程等情况都会导致dump.rdb缺失或大小为0，但客户端收不到错误。
- 每次
BGSAVE后，用redis-cli LASTSAVE比对时间戳，确认是否真有新快照落地 - 配合监控脚本检查
redis_dir/dump.rdb文件大小：[ -s /var/lib/redis/dump.rdb ] || echo "RDB file empty!" - 如果启用了
stop-writes-on-bgsave-error yes（默认开启），BGSAVE失败会导致后续所有写命令报MISCONF Redis is configured to save RDB snapshots，这点极易被忽略
RDB与AOF混用时，RDB快照实际生效时机更复杂
当同时开启appendonly yes和save配置时，Redis重启优先加载AOF；但若AOF被关闭或损坏，才会回退到RDB。此时你精心安排的RDB快照，可能一年都用不上。
- 用
CONFIG GET appendonly和CONFIG GET aof-use-rdb-preamble确认当前持久化模式 - 如果业务能接受秒级数据丢失，建议关掉AOF，专注维护RDB策略——减少一个变量，故障面直接减半
- 若必须开AOF，RDB仅作为冷备，那就别在高峰期以外花精力调优RDB参数，重点盯AOF rewrite的资源占用
真正难的不是设几个save参数，而是搞清你的数据到底靠哪个文件恢复、谁在什么时候真正读取它。快照策略永远要跟着恢复路径走，而不是配置项走。
