serverCron 每100ms检查一次，仅当无RDB/AOF子进程时，才根据saveparams（dirty+lastsave）触发RDB，或根据AOF状态、大小及增长率触发AOF重写；改配置不重置计时/计数，故不立即生效。
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 的逻辑是“机会主义”的，它不保证任何事一定发生，只保证“在安全窗口里，按规则择机执行”。所有依赖它的行为——比如备份节奏、磁盘空间预估、故障恢复点——都得把这种不确定性算进去。
