限制等待而非证明对端状态
调用者可以为连接、读取或整次请求设定等待期限,超出后报告超时或采取后续动作。必须先说明计时覆盖哪一段:连接建立和取得业务响应不是同一个阶段,DNS或TLS也可能不包含在某个底层选项内。
超时只说明在适用期限内没有取得所需结果。远端可能尚未开始,也可能仍在执行,甚至已经完成而响应未到;Amazon的实践说明因此强调,带副作用的重试需要考虑幂等语义。
参考:[1]
等待结束不总会取消执行
Python的concurrent.futures.Future.result可以在指定时间后抛出TimeoutError,但取消是另一个接口;已经运行的调用可能无法通过Future.cancel停止。因此等待者离开,并不能代替对后台工作最终归宿的管理。
Go的WithTimeout建立带截止时间的上下文,向使用它的操作传递取消信号;操作仍须观察并配合该信号。超时、发出取消和确认收尾,是经常一起出现却需要分别核对的步骤。
期限与重试共同影响负载
期限过长会让资源持续被占用,过短则可能把正常的较慢响应误判为失败,并制造更多重试。设定时需要考虑延迟分布、连接是否复用,以及调用链上其他等待预算,而不只取一个看起来响应很快的数字。
故障来自过载时,立即重试还可能继续加重负担。Amazon讨论使用有限重试、退避和随机抖动分散请求;这些策略改变失败处理与资源消耗,不能把超时简单理解为“到点以后再发一次就好”。
参考:[1]