第三秒到点，对方的售票系统没回话，我方点了两次重试，客人手里多出两笔单。值班的信息科把超时重试当成了一件事来说，其实超时、重试、重复是三截。票务系统要回答的，是阈值定在哪、由谁重试、重复了怎么认。

超时重试的三秒是判据，不是结论

接口超时阈值定 3 秒，意思是等满 3 秒还没拿到回执，就判这一笔暂无结果，不等于对方没做成。回执就是对方回的那一句我收到了，两边靠它对上号。三秒到点没回执，这一笔在两边各是什么状态，只有翻日志比过才知道。所以头一次要做的不是马上重试，是先看这一笔有没有带着请求标识出去。

重试两次算几笔，票务系统挡不挡得住重复

超时重试的上限写在对接说明上：调用方重试上限 2 次。两次之内落在同一个请求标识上的，按一笔处理，结果只回一次。没有带请求标识的重试，一律生成新单，并在对账里标疑，等人来看。票务系统挡重复靠的就是先比这个号，比上了把原来的结果原样退回，比不上才新开一笔。

请求标识说白话就是跟着这一笔走的一个号，谁发的、第几次发的都记在它身上。有它，两次点击能并成一笔；没它，两次点击就是两笔门票，客人手里多出一张用不上的单。

重复单一经确认，作废其中一笔并留下关联。留关联的意思是作废那一笔不删，两笔之间能互相查到，客人那边只有一张有效门票，另一张的状态和作废原因都写在单上。售票系统里删单不留痕，财务对账时就少一条能解释的线。

谁来重试：调用方重试还是服务方自动重试

两条路各走一遍。由调用方重试，每一次点击都落在我方日志里，重试了几次、隔了多久，对账时按请求标识一笔一笔数得清。由服务方自动重试，我方只看最终结果，中间试了几回不知道，客人重复下单时说不清是谁发起的。越往后的对账越依赖来源，调用方这条少吵。

查超时重试有没有生效，方法很短。挑一段客流不高的时段，主动制造一次超时，把这一笔正常发起之后就不动它，看后续 5 分钟内票务系统里生成了几笔单。落一笔算合格，落两笔就是重试没带请求标识。再拿这笔单去售票系统的订单表里按同一个手机号查，两笔都在，说明重复已经漏到游客手上。

三秒和两次这两条一旦改动，要通知到所有渠道，不能只改自己那一份说明。改完往后的几天，每天按请求标识抽查一次，看有没有渠道还按旧的次数在发。抽出不一致的，当场记下渠道名和笔数，攒到月底再说就查不清是谁发的。

比完当天要落一张小单：发起时间、回执时间、重试次数、落了几笔、有没有标疑。这张单是后面判断阈值定得合不合适的唯一凭据，也是渠道之间吵架时能拿出来的东西。

只有在查询类接口上，这套约束不用。查余量、查订单状态这类只看不改的接口，重试多少次都不会生成新单，超时重试那两条上限不参与，可以自由重试。凡是涉及出票和支付的接口，一次都不许自由重试，三秒阈值和两次上限照旧执行。