Redis持久化触发机制详解

Redis的持久化并非依赖固定时间点的硬性触发，而是由每100毫秒执行一次的serverCron函数以“机会主义”方式动态决策：仅在无RDB/AOF子进程运行的安全窗口内，结合dirty计数器、lastsave时间戳、AOF当前大小与增长率等实时状态，判断是否启动RDB快照或AOF重写；配置变更（如save规则或AOF阈值）会立即更新参数但不重置计时/计数器，因此不会立即生效，需等待自然积累达标或手动触发；同时，fork失败时通过冷却机制避免日志刷屏，而AOF重写卡住也不会阻塞serverCron主线程——这种轻量、非确定、强依赖运行时状态的设计，让持久化行为既高效又隐晦，也给运维监控和故障排查带来了独特挑战。

serverCron 里什么时候决定该 RDB 或 AOF 重写？

Redis 不靠定时器硬触发持久化，而是靠 serverCron 每 100ms 扫描一次状态，再根据条件“顺手”发起 RDB save 或 AOF rewrite。关键不是“到了点就做”，而是“这次轮到我检查时，发现满足了就做”。

• serverCron 中调用 updateCachedTime 后，紧接着执行 if (server.rdb_child_pid == -1 && server.aof_child_pid == -1) —— 只有没子进程在干活时，才考虑新启一个
• RDB 触发看 server.saveparams 数组：比如配置了 save 300 10，表示“最近 300 秒内至少 10 次变更”，server.dirty 计数器和 server.lastsave 时间戳共同参与判断
• AOF 重写触发看两个开关：server.aof_state == AOF_ON 且 server.aof_rewrite_scheduled == 0；真正启动前还会比对 server.aof_current_size 和 server.aof_rewrite_min_size（默认 64MB），以及增长比例 server.aof_base_size

为什么改了 save 配置但 RDB 就是不触发？

常见现象是改了 redis.conf 里的 save 行，reload 配置后，server.dirty 一直涨，却始终没看到 Background saving started 日志。根本原因在于：Redis 加载配置时只覆盖 server.saveparams，但不会重置 server.lastsave 或清空 server.dirty。

• 如果上次成功 save 是 299 秒前，你刚 reload 配置，此时 dirty=5，那即使配了 save 300 10，也不会触发——差 5 次变更
• CONFIG SET save "300 10 60 1000" 会实时更新 server.saveparams，但同样不重置计时/计数，行为一致
• 真正想立刻触发，得手动 SAVE 或 BGSAVE；或者等下一个 cron 周期，靠自然积累达标

fork 失败时，serverCron 怎么避免反复重试？

当系统内存不足或 vm.overcommit_memory=0 时，fork() 调用失败，serverCron 不会立刻报错退出，而是设一个冷却标记，跳过后续几轮检查。

• 失败后设置 server.rdb_save_time_last = time(NULL)，并在下次进入时检查：if (time(NULL)-server.rdb_save_time_last 就直接 return，相当于“两秒内不再尝试”
• 这个冷却仅作用于 RDB，AOF rewrite 有自己的类似逻辑（server.aof_rewrite_time_last）
• 注意：这个机制不解决根本问题，只是防刷屏日志；若持续 fork 失败，INFO persistence 里 rdb_last_bgsave_status:err 会长期为 err

为什么 AOF rewrite 有时卡住，但 serverCron 还在跑？

serverCron 本身不阻塞，它只负责“发起”和“检查”，真正的 AOF rewrite 是子进程干的。你看到 Redis 主线程响应正常，不代表 rewrite 已完成；而 serverCron 每次进来只会看 server.aof_child_pid != -1 就跳过调度，不会管子进程卡在哪。

• 子进程卡在写文件（比如磁盘满、IO 堵塞）、或正 dump key 空间（大 hash / zset 序列化慢），主线程完全感知不到细节
• serverCron 中的 wait3(&statloc, WNOHANG, NULL) 只做非阻塞收割，不主动 kill；超时控制靠上层配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 的下一次评估
• 排查时优先看 INFO persistence 里的 aof_rewrite_in_progress:1 和 aof_last_rewrite_time_sec:-1（负值说明还在跑）

真正难 debug 的地方在于：serverCron 的逻辑是“机会主义”的，它不保证任何事一定发生，只保证“在安全窗口里，按规则择机执行”。所有依赖它的行为——比如备份节奏、磁盘空间预估、故障恢复点——都得把这种不确定性算进去。

今天关于《Redis持久化触发机制详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！