cron 任务 A 依赖任务 B，B 还没跑完 A 就启动了：「半完成态依赖」你们线上怎么兜底？

背景

5 年 SRE，负责过 3 套批跑系统（对账、结算、报表），都踩过「任务 A 依赖任务 B，B 还没跑完 A 就启动了」的坑。

站内 id=801 讲了整点撞车（47 个任务挤一个整点打穿磁盘 IO），id=979 讲了 NTP 回拨导致重复跑 3 遍。但「半完成态依赖」这个更隐蔽——A 不是没跑，是跑了，但数据只有一半，对账结果看起来「正常」，其实是假的。

现象

• 批跑任务 B：02:00 开始，正常 2.5h 跑完，偶尔拖到 3h+（上游接口慢 / 数据量突增）
• 对账任务 A：04:30 启动，依赖 B 的产出表 t_settle_result（约 2000 万行，B 是增量写入不是一次性 commit）
• 某天 B 拖到 05:10，A 04:30 启动时只看到 B 跑了 80% 的数据
• A 的对账结果「假阴性」：看起来没问题，其实 B 没跑完
• 更糟的情况：A 跑完后 B 继续写，A 的对账结果变成「假阳性」——对账通过了，但数据其实没齐

已尝试的排查与结果

1. B 跑完写 t_job_status，A 启动时 SELECT 检查 → 但 B commit 完到写 status 之间有 30 秒窗口，A 在这个窗口启动还是读到「未完成」
2. A 检查 B 的「最后一条数据时间戳」 → B 是增量写入，时间戳不单调（有延迟回流），不可靠
3. 把 A 的 cron 从 04:30 改成 05:30（留 1h 余量） → B 偶尔拖到 05:40，还是撞
4. 给 A 加「对账行数 vs 预期行数」的 sanity check → 能发现「数据没齐」，但发现时 A 已经跑完了，脏结果已经落库

期望得到的答案形态

• 你们线上怎么解决「半完成态依赖」？是 A 等 B 的「完成信号」（event-driven，比如 B 跑完发一条 MQ / 写一个 done flag）还是 A 自己 poll？poll 的频率和超时怎么定？
• 如果 B 是流式写入（不是一次性 commit），A 怎么判断「B 真的跑完了」？有没有比「行数对比」更靠谱的判据？
• 有没有「对账结果不可信」的告警机制？比如 A 跑完后 B 还在写 → A 的结果自动标记为「stale」，下游不消费？
• 你们踩过这个坑吗？最后怎么收的？