2024年12月16日，一名开发者针对开源后台任务框架 Trigger.dev 提交了一份错误报告。一次常规的夜间服务器重启导致随机任务卡在“排队”状态。系统的恢复逻辑完全按照设计运行，检测到停滞的任务并将其重新加入队列。随后，它再次检测到这些任务。一次又一次。当有人检查仪表盘时，队列中已经积压了3,800个重复任务，每一个都是对已完成工作的忠实复制。
监控系统没有显示任何错误。每个任务都成功了。重复的任务也在成功执行。从系统的角度来看，没有任何问题。
这类错误会让资深工程师陷入沉默。不是因为它的复杂性——解释只需一句话——而是因为其含义令人不安。系统并没有发生故障。它完全按照设计意图行事：检测被遗弃的工作并重试。问题在于，“成功完成”和“静默遗弃”从外部产生的信号是相同的。两者都会归于沉寂。
两将军问题与无解的困境
这一问题的理论基础比当今大多数生产系统都要古老。1985年，菲舍尔（Fischer）、林奇（Lynch）和帕特森（Paterson）在《美国计算机协会期刊》上发表了他们的不可能性结果：鉴于即使存在单个故障进程的可能性，进程系统也无法就决策达成一致。这篇论文正式讨论的是共识问题，但其实际影响涉及更平凡的事物。它关乎确认机制。
你发送一条消息。它到达了吗？你等待确认。确认到达了吗？你可以发送对确认的确认，但这只是将问题提升了一个层级。这就是“两将军问题”，且它没有解决方案。不是“没有已知解决方案”，而是根本没有解决方案，绝无可能。这是一种数学上的不可能性，对于分布式计算而言，其基础性与停机问题对于计算本身一样根本。
泰勒·特里特（Tyler Treat）在2015年的一篇散文中提炼出了这一实际后果，该文章此后成为某种经典参考：“你无法实现精确一次交付。”他认为，实际上只有两种真正的交付语义。至多一次：在处理消息之前进行确认，接受崩溃会导致数据丢失。至少一次：在处理之后进行确认，接受重试会导致工作重复。其他所有情况不过是这两种情况的变体，只是换了一层更好的包装。
“实践中的精确一次交付，”特里特写道，“是通过伪装实现的”——通过幂等操作、去重层或应用层状态机，使得即使底层传输无法使重复处理变得不可能，也能让重复处理变得安全。Apache ZooKeeper 的 Zab 协议展示了这种方法：状态变更是幂等的，因此多次应用相同的变更不会产生不一致。但这是一种应用层保证，而非网络层保证。网络仍然会多次传递消息。只是应用程序学会了不在意。
理论表明重复是不可避免的。问题不在于你的系统是否会重复工作。而在于它是否会察觉到。
行业已公开承认这一点
这使得 Trigger.dev 事件不那么令人惊讶，却更具谴责意味的部分在于。全球最大的云服务提供商不仅承认重复执行的存在。他们还将其记录为预期行为。
Google Cloud Tasks 直白地指出：“在必须在保证执行和重复执行之间做出设计权衡的情况下，服务倾向于保证执行。”他们公布的指标显示：超过 99.999% 的任务仅被执行
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
