AetherGrid

大家好，我是 Wycliffe，AetherGrid 的作者。

我之所以做这件事，是因为一种非常具体的痛点。多年来我一直在生产系统中追踪竞态条件——先是在全国范围内处理真金白银交易收入的系统，然后是丰田的 worker 队列，现在则是以审阅 LLM 生成的后端代码为生。模式总是一样的：代码在正常路径下运行良好，但在执行过程中一旦出问题就会崩溃。一个 worker 崩溃、网络抖动一次、心跳丢失一次，两个进程就突然都认为它们拥有同一个任务。

大多数调度器类的副业项目都不会处理这类问题，因为它们本质上只是一个在 while 循环里轮询字典的脚本。它能用，直到不能用为止。我想构建一个不会倒下的版本，因此在 AetherGrid 中，任务的执行所有权运行在有期限的租约之上——租约会在任务整个运行期间持续续期，而不是一个在出问题的瞬间就会对你撒谎的布尔标志。

随着构建过程的推进，我的方法也发生了很大变化。我一开始只想要一个能用的调度器，但越深入研究故障恢复，就越意识到真正有趣的工程问题不是如何调度任务，而是在事情出错时如何安全地取消调度。租约、协调机制以及有界重试逻辑正是由此而来。我最终写了一个测试，会真正地杀掉一个忽略 SIGTERM 的子进程，只是为了证明超时强制机制在压力下也能真正生效，而不仅仅停留在理论上。

目前它已经在线上生产环境运行，背后有 280 个测试，并有 26 份 ADR 记录了每一个不太直观决策背后的原因。很乐意回答任何关于架构、租约机制，或为什么我选择使用原生 psycopg 而不是 ORM 的问题。也非常真诚地想听听大家在各自系统中是如何处理执行所有权的。