接口超时

Posted 2023-04-03

参考技术A 当设计的业务流程或者功能需要调用其他接口实现请求与响应的时候，可能由于网络等原因导致的接口超时导致业务中断或者功能反馈有误等。所以，对接口超时的知识做一个积累。

1、接口资源（mysql、Redis、Memcached、HTTP 接口）具备这样一些特点：

（1）都是网络接口：网络会成为影响因素

（2）这些资源的可用性，连接速度、读取速度不可控

（3）分层模式，对于调用方来说，只明确是否能够读取数据、数据是否正确；对于资源提供方来说负责具体的数据逻辑。

2、所以涉及到接口开发时，需要注意（产品更多的关注点）

（1）超时机制：对于资源可能会很慢，对于应用程序来说，一个 HTTP 接口，假如返回数据需要十秒，本身是不可接受的那么，所以需要一个超时机制，结束这个资源调配的进程

（2）重试机制：假如一个资源特别重要，可以采取失败重试。比如下单跟第三方接口确认订单时，出现中断等原因导致接口返回有误，可以进行重试请求

（3）异常处理机制：当请求或者返回出现问题，导致功能无法正确发挥效果的时候，不应该仅是简单处理为返回空值，最好能明确产生异常的原因。同时，告知用户该操作失败的原因，和操作补偿，怎么样才让用户将该流程继续。

3、与用户的交互 （产品更多的关注点）

http://naotu.baidu.com/file/51ee300b0b53b79a9a8e52ecd9a40e69?token=fa42fb62487d60fb

4、研发技术上可能可以尝试的解决方案：

（1）增加超时时间

假设A系统有个方法methodA，会调用B系统的methodB这个http接口，如果mehodA不追求超快的 响应速度 ，那么你在调用methodB这个http接口时，可以增长超时时间，例如10秒超时。因为经常在某些时刻，由于网络原因或者系统原因，调用method会超时的。

（2）尝试多调用一次

如果第一次调用methodB超时了，那么你可以尝试多调用一次。当然前提是，methodA不追求超快的响应时间。

（3）使用待处理队列

如果methodA需要很快的响应速度，那么当调用methodB接口超时时，可以使用一个队列存储本次失败的记录，然后使用一个job每隔一段时间去扫这个队列，看看是否有待处理的数据。

备注：如果对方系统挂掉了，使用待处理队列的方式，比较合适。

（4）回滚数据

catch这个超时异常，然后记录日志后，抛出这个异常，并把之前的数据回滚。让对方的系统重新调用。

备注:宁愿没有数据，也不要存储脏数据。

（5）使用异步机制

如果你的业务方法中，需要调用对方的http接口，如果这个http接口不影响主流程的，那么可以使用一个线程，异步调用对方的http接口，并把超时时间设置长一些。由于使用了异步，主流程会立刻继续走的。

（6）问题：调用第三方支付接口响应时间超过10秒，导致大量线上订单因为超时失败，该接口是实时返回结果的，而且不是一直都慢，是偶尔慢。

解决方法：调用接口时设置超时时间，当接口超过9秒未返回结果， 自动将改订单设置为处理中 ，然后后由定时任务调用查询接口。

这样就把，一个实时返回结果的接口，当成一个异步的接口来用了，总比一大堆失败订单等着财务来找好。

可查看链接：

http://wulijun.github.io/2012/08/08/php-timeout-summary.html

http://www.jianshu.com/p/8555ce285375

接口调用过于频繁会引发超时错误吗

参考技术A 应该不会
引起接口响应超时有两种原因。第一种原因，服务器端超时参数设置过小，导致客户端的请求来不及被处理，就被服务器判定为超时并返回。引起接口响应超时的第二种原因，是服务器端执行该接口请求时出现了运行时异常。这种情况下，接口请求永远无法返回给客户端，必须先修复引起该运行时错误的问题根源。