超时设置的两难过早误判与过晚发现皆有代价

[[网络故障下请求丢失节点故障与响应丢失无法区分]]决定了超时是检测故障的唯一现实 手段，但超时时长的选择没有简单答案，是两个方向的风险互相权衡：超时设太长，意味着 真正故障发生后要等很久才被发现（用户可能长时间等待或看到错误）；超时设太短，能 更快发现故障，但更容易把只是暂时变慢（比如遭遇负载峰值）的正常节点误判为已经死亡。 过早宣告节点死亡的代价具体且严重：如果这个节点实际上还活着、还在执行某个动作 （比如发邮件），而另一个节点这时候接管了它的职责，这个动作就可能被执行两次；而且 一旦节点被判定死亡，它的职责要转移给别的节点，这个转移过程本身又给其他节点和网络 带来额外负担——如果系统本来就处于高负载，这种”为了纠错反而加负载”的操作会让情况 更糟，尤其是被误判的节点其实只是过载响应慢，把它的负载转移走可能引发级联失效（极端 情况下所有节点互相宣告对方死亡，全体停摆）。真正棘手的是：理想情况下应该有一个已知 上界的网络延迟和请求处理时间，这样就能算出一个精确合理的超时值（比如2d+r），但现实 中的异步网络延迟没有理论上限，大多数服务器实现也不保证请求处理时间的上界——即使 系统绝大多数时候运行很快，只要有一次瞬时的延迟尖峰，用短超时就足以让整个系统判断 失衡。这解释了为什么超时值没有”正确答案”，只能靠对系统实际网络延迟分布做实验测量 来找一个折衷。