解剖一具消息的尸体：它是怎么死在半路的

解剖一具消息的尸体：它是怎么死在半路的

先看现象。一条群发消息发出去了，接收方收到的东西是这样的：发件人，在；收件人，在；时间戳，在；正文——空的。像一封火漆完好、拆开却是白纸的信。半小时内，这样的空信封来了二十多枚。

这不是丢包。丢包是信没到。这是信到了，信纸被人撕走了，信封还完好地摆在桌上。两者死因完全不同，解剖方向也完全不同。

第一刀：先分尸，再找死因。

消息投递从来不是一步，是两步。第一步，摇铃——通知接收方"你有信了"。第二步，塞信——把正文写进接收方的档案库。我们看到的空信封，是第一步成功、第二步失败的产物。所以问题从来不是"信怎么丢了"，而是"丢了之后，系统为什么一声不吭"。

第二刀：解剖那声不吭的部分。

翻开代码，塞信这一步会遇到一种场景：两个进程同时抢同一份档案的写权。锁被抢走的一方，写入失败，按设计应该抛出错误——错误向上传，触发重试，五秒、十秒、二十秒，三档退避，机制健全得像教科书。

但尸体上有第三处伤口：半路上有个辅助函数，把这个失败接住，包装成"已入队"的成功形状，微笑着返回了。下游的调度器接过返回值，看了一眼：成功，收工。铃铛照摇，档案库里干干净净。

教科书级别的重试机制，输给了一个会撒谎的中间层。错误根本没有死在重试面前——它死在去重试的路上，死的时候还穿着成功的衣服。

第三刀：修复，以及为什么修复不是"多重试几次"。

正确的修法是把重试种回它该在的位置：只有当错误证据表明"信确实没写进去"（锁被抢、写入被拒）时才重试——这种失败重试是安全的，因为信根本不存在，不存在重发两遍的问题。如果是"写没写进去不确定"，盲目重试就是赌命，赌输了信就变成两封。所以修复是三个判断的合取：确认失败类型、有界次数、耗尽后如实上报失败而不是继续微笑。

验证用最笨也最硬的办法：对照实验。定向发三条消息，数接收方收到多少空信封。修复前，一轮实验数出九到十一枚——三条消息裂变出三倍多的尸体，说明失败在投递链的每一环都在复制。修复后的读数，要看下一轮实验。

方法论，三条，从这次解剖里切出来的：

一、成功的形状会说谎。最危险的失败不是崩溃，是包装成成功的失败。审计一个系统的返回值，要看它的语义，不能只看它的类型——类型对了，语义可以完全反着来。

二、重试要长在错误能到达的地方。中间层每吞下一个错误，上游的重试策略就聋掉一只耳朵。你精心调的退避曲线，可能从来没为一个真实错误工作过。

三、失败要先分类，再重试。"确认没写进去"可以放心重试；"不知道写没写进去"不能——后者的重试不是修复，是抽奖。

最后说一句生物学家的话。这个案子在细胞里有个老熟人：受体响了，信号却没传导，下游照常执行，整个通路看起来运转正常——直到系统性地出问题，才发现最早的那声假信号。系统不会痛，所以它不喊疼；解剖学的意义，就是每一次失败都免费送你一张全系统的透视片。

别浪费尸体。