接口超时的处理思路

问题背景

在一个很普遍的场景中，涉及到双端通信的情况下，不论是传统的单机服务，还是现在的微服务，甚至事异步通信技术(进程内，进程与进程)，一直都存在着三态的问题，即成功，失败，超时。
如下图两个服务间:

成功失败具有明确的业务语义和边界，正常处理即可。最复杂的就是超时，因为网络通信原因，双端都不确定哪个环节超时。

处理思路简述

1. 先保证接口幂等性
2. 多次不同步长的间隔时间去重试请求/反馈
3. 服务端提供主动查询接口

应用场景与处理思路

1. 同步调用超时

超时点：

1. 请求超时。
2. 服务端内部处理超时:比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开连接。
3. 服务端处理正常，但响应结果阶段超时。

处理：
客户端
无论那个阶段，客户端都不确定请求是否被应答，即服务端处理的结果，客户端不知道是否成功。客户端此时能做的，有两种方法：

1. 重试，客户端需要主动做好重试方案，比如类似mq的重试队列(1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h)，主要的技术，spring-retry框组件，将请求扔到自产自销的 mq，依靠mq的重试队列主动重试，或者建立定时任务表重试。
   不管哪种方式，需要服务端接口具备幂等性
2. 主动查询结果，超时后客户端主动查询，查询的时机类似重试机制，因为快速的查询，并不总是有 效，当发生网络抖动的时候，很大概率就地查询，也是网络抖动阶段。

服务端
服务端不存在请求超时和响应超时，但存在自身超时的情况，解决方案：

1. 自身 rt¹ 值需要优化，比如慢sql等
2. 以来三方接口的时候，跟第三方接口又形成了一个客户端-服务端模式，根据具体场景或者快速失败， 或者做好容错措施，必要的时候，还会有比如金融领域的冲正操作。

2. 异步调用超时

异步调用，类似ajax，客户端同步请求，服务端异步响应。

超时点：

1. 请求超时。
2. 服务端内部处理超时:比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开连接。
3. 服务端处理正常，但响应结果阶段超时。
4. 异步响应超时

处理：
客户端
参考同步调用超时-客户端
服务端
服务端不存在请求超时和同步响应超时，对于内部处理超时，同同步情况一样。那么就只剩下异步响应超时了。
比较有代表性的就是支付结果通知，可参考 支付结果通知文档
存在此问题就是服务端通知客户端的时候(客户端需要同步提供响应服务端结果通知的接口)，未接受到客户端的响应。

3. MQ超时

MQ超时问题相当于另外一个话题，如何保证mq不丢消息，无论是kafka和RocketMQ，都支持ack的机制，用以确认消息的发送和接受的成功。由于内容较多，在后续的文章里，再进行梳理和分享。

---

1. 服务端处理一次请求所需要的平均处理时间 ↩︎