【接口】接口超时原因分析

news2024/9/19 17:53:14

接口超时的原因：

一、网络抖动

有可能是你的网络出现抖动、网页请求API接口、接口返回数据给网页丢包了。

二、被带宽占满

用户量暴增，服务器网络带宽被占满。

服务器带宽：一定时间内传输数据的大小，如：1s传输10M的数据

用户请求量增多，1s传输了100M，导致1s内，有90M的数据延迟传输，导致接口超时。

如何增加服务器带宽？

以NIGNX为例：

修改nginx配置文件中图片访问的配置部分
对于正常小图的访问不限制，把正常图的大小限定为 100K 以内，超出时就进行限速，速度限定为最大 100k/s

location ~ .*\.(gif|jpg|jpeg|png|bmp)$
{
expires 30d;
limit_rate_after 100k;
limit_rate 100k;
}

三、线程池满了

有时候为了性能考虑，可能会使用线程池异步查询数据，最后把查询结果进行汇总，然后返回。

public UserInfo getUserInfo(Long id) throws InterruptedException, ExecutionException {
    final UserInfo userInfo = new UserInfo();
    CompletableFuture userFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteUserAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);

    CompletableFuture bonusFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteBonusAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);

    CompletableFuture growthFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteGrowthAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);
    CompletableFuture.allOf(userFuture, bonusFuture, growthFuture).join();

    userFuture.get();
    bonusFuture.get();
    growthFuture.get();

    return userInfo;
}

executor，表示自定义的线程池，为了防止高并发场景下，出现线程过多的问题。

但如果用户请求太多，线程池中已有的线程处理不过来，线程池会把多余的请求，放到队列中排队，等待空闲线程的去处理。

如果队列中排队的任务非常多，某次API请求一直在等待，没办法得到及时处理，就会出现接口超时问题。

如何解决？

1、是否核心线程数设置太小了？

corePoolSize=> 线程池里的核心线程数量
maximumPoolSize=> 线程池里允许有的最大线程数量

2、有多种业务场景共用了同一个线程池？

四、数据库死锁

你提供的API接口中通过某个id更新某条数据，此时，正好线上在手动执行一个批量更新数据的sql语句。

该sql语句在一个事务当中，并且刚好也在更新那条数据，可能会出现死锁的情况

五、传入参数太多

如果接口调用方，一次性传入几千个，甚至几万个id，批量查询分类，也可能会出现接口超时问题。

查询条件太多，有可能走全表扫描更快。所以这种情况下sql语句可能会丢失索引，让执行时间变慢，出现接口超时问题

因此我们在设计批量接口的时候，建议要限制传入的集合的大小，比如：500。

六、API超时设置

monitor:
  rest-template:
    readTimeout: 10000
    connectTimeout: 10000
    connectionRequestTimeout: 1000
  http-request:
    socketTimeout: 10000
    connectTimeout: 10000
    connectionRequestTimeout: 10000

如何做不同业务场景超时时间不同？