关于java:从20s优化到500ms我用了这三招

33次阅读

共计 5388 个字符,预计需要花费 14 分钟才能阅读完成。

前言

接口性能问题,对于从事后端开发的同学来说,是一个绕不开的话题。想要优化一个接口的性能,须要从多个方面着手。

本文将会接着接口性能优化这个话题,从实战的角度登程,聊聊我是如何优化一个慢查问接口的。

上周我优化了一下线上的批量评分查问接口,将接口性能从最后的 20s,优化到目前的 500ms 以内。

总体来说,用三招就搞定了。到底经验了什么?

1. 案发现场

咱们每天早上下班前,都会收到一封线上查问接口汇总邮件,邮件中会展现接口地址、调用次数、最大耗时、均匀耗时和 traceId 等信息。

我看到其中有一个批量评分查问接口,最大耗时达到了 20s,均匀耗时也有 2s。

用 skywalking 查看该接口的调用信息,发现绝大数状况下,该接口响应还是比拟快的,大部分状况都是 500s 左右就能返回,但也有少部分超过了 20s 的申请。

这个景象就十分奇怪了。

莫非跟数据无关?

比方:要查某一个组织的数据,是十分快的。但如果要查平台,即组织的根节点,这种状况下,须要查问的数据量十分大,接口响应就可能会十分慢。

但事实证明不是这个起因。

很快有个共事给出了答案。

他们在结算单列表页面中,批量申请了这个接口,但他传参的数据量十分大。

怎么回事呢?

当初说的需要是这个接口给分页的列表页面调用,每页大小有:10、20、30、50、100,用户能够抉择。

换句话说,调用批量评估查问接口,一次性最多能够查问 100 条记录。

但理论状况是:结算单列表页面还蕴含了很多订单。基本上每一个结算单,都有多个订单。调用批量评估查问接口时,须要把结算单和订单的数据合并到一起。

这样导致的后果是:调用批量评估查问接口时,一次性传入的参数十分多,入参 list 中蕴含几百、甚至几千条数据都有可能。

2. 现状

如果一次性传入几百或者几千个 id,批量查问数据还好,能够走主键索引,查问效率也不至于太差。

但那个批量评分查问接口,逻辑不简略。

伪代码如下:

public List<ScoreEntity> query(List<SearchEntity> list) {
    // 后果
    List<ScoreEntity> result = Lists.newArrayList();
    // 获取组织 id
    List<Long> orgIds = list.stream().map(SearchEntity::getOrgId).collect(Collectors.toList());
    // 通过 regin 调用近程接口获取组织信息
    List<OrgEntity> orgList = feginClient.getOrgByIds(orgIds);
    
    for(SearchEntity entity : list) {
        // 通过组织 id 找组织 code
        String orgCode = findOrgCode(orgList, entity.getOrgId());
    
        // 通过组合条件查问评估
        ScoreSearchEntity scoreSearchEntity = new ScoreSearchEntity();
        scoreSearchEntity.setOrgCode(orgCode);
        scoreSearchEntity.setCategoryId(entity.getCategoryId());
        scoreSearchEntity.setBusinessId(entity.getBusinessId());
        scoreSearchEntity.setBusinessType(entity.getBusinessType());
        List<ScoreEntity> resultList = scoreMapper.queryScore(scoreSearchEntity);
        
        if(CollectionUtils.isNotEmpty(resultList)) {ScoreEntity scoreEntity = resultList.get(0);
            result.add(scoreEntity);
        }
    }
    return result;
}

其实在实在场景中,代码比这个简单很多,这里为了给大家演示,简化了一下。

最要害的中央有两点:

在接口中近程调用了另外一个接口

须要在 for 循环中查问数据

其中的第 1 点,就是:在接口中近程调用了另外一个接口,这个代码是必须的。

因为如果在评估表中冗余一个组织 code 字段,万一哪天组织表中的组织 code 有批改,不得不通过某种机制,告诉咱们同步批改评估表的组织 code,不然就会呈现数据不统一的问题。

很显然,如果要这样调整的话,业务流程上要改了,代码改变有点大。

所以,还是先放弃在接口中近程调用吧。

这样看来,能够优化的中央只能在:for 循环中查问数据。

3. 第一次优化

因为须要在 for 循环中,每条记录都要依据不同的条件,查问出想要的数据。

因为业务零碎调用这个接口时,没有传 id,不好在 where 条件中用 id in (…),这形式批量查问数据。

其实,有一种方法不必循环查问,一条 sql 就能搞定需要:应用 or 关键字拼接,例如:(org_code=’001′ and category_id=123 and business_id=111 and business_type=1) or(org_code=’002′ and category_id=123 and business_id=112 and business_type=2) or(org_code=’003′ and category_id=124 and business_id=117 and business_type=1)…

这种形式会导致 sql 语句会十分长,性能也会很差。

其实还有一种写法:

where (a,b) in ((1,2),(1,3)...)

不过这种 sql,如果一次性查问的数据量太多的话,性能也不太好。

竟然没法改成批量查问,就只能优化单条查问 sql 的执行效率了。

首先从索引动手,因为革新老本最低。

第一次优化是优化索引。

评估表之前建设一个 business_id 字段的一般索引,然而从目前来看效率不太现实。

因为咱们果决加了联结索引:

alter table user_score add index  `un_org_category_business` (`org_code`,`category_id`,`business_id`,`business_type`) USING BTREE;

该联结索引由:org_code、category_id、business_id 和 business_type 四个字段组成。

通过这次优化,成果空谷传声。

批量评估查问接口最大耗时,从最后的 20s,缩短到了 5s 左右。

4. 第二次优化

因为须要在 for 循环中,每条记录都要依据不同的条件,查问出想要的数据。

只在一个线程中查问数据,显然太慢。

那么,为何不能改成多线程调用?

第二次优化,查询数据库由单线程改成多线程。

但因为该接口是要将查问出的所有数据,都返回回去的,所以要获取查问后果。

应用多线程调用,并且要获取返回值,这种场景应用 java8 中的 CompleteFuture 十分适合。

代码调整为:

CompletableFuture[] futureArray = dataList.stream()
     .map(data -> CompletableFuture
          .supplyAsync(() -> query(data), asyncExecutor)
          .whenComplete((result, th) -> {})).toArray(CompletableFuture[]::new);
CompletableFuture.allOf(futureArray).join();

CompleteFuture 的实质是创立线程执行,为了防止产生太多的线程,所以应用线程池是十分有必要的。

优先举荐应用 ThreadPoolExecutor 类,咱们自定义线程池。

具体代码如下:

ExecutorService threadPool = new ThreadPoolExecutor(
    8, //corePoolSize 线程池中外围线程数
    10, //maximumPoolSize 线程池中最大线程数
    60, // 线程池中线程的最大闲暇工夫,超过这个工夫闲暇线程将被回收
    TimeUnit.SECONDS,// 工夫单位
    new ArrayBlockingQueue(500), // 队列
    new ThreadPoolExecutor.CallerRunsPolicy()); // 回绝策略 

也能够应用 ThreadPoolTaskExecutor 类创立线程池:

@Configuration
public class ThreadPoolConfig {

    /**
     * 外围线程数量,默认 1
     */
    private int corePoolSize = 8;

    /**
     * 最大线程数量,默认 Integer.MAX_VALUE;
     */
    private int maxPoolSize = 10;

    /**
     * 闲暇线程存活工夫
     */
    private int keepAliveSeconds = 60;

    /**
     * 线程阻塞队列容量, 默认 Integer.MAX_VALUE
     */
    private int queueCapacity = 1;

    /**
     * 是否容许外围线程超时
     */
    private boolean allowCoreThreadTimeOut = false;


    @Bean("asyncExecutor")
    public Executor asyncExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(corePoolSize);
        executor.setMaxPoolSize(maxPoolSize);
        executor.setQueueCapacity(queueCapacity);
        executor.setKeepAliveSeconds(keepAliveSeconds);
        executor.setAllowCoreThreadTimeOut(allowCoreThreadTimeOut);
        // 设置回绝策略,间接在 execute 办法的调用线程中运行被回绝的工作
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        // 执行初始化
        executor.initialize();
        return executor;
    }
}

通过这次优化,接口性能也晋升了 5 倍。

从 5s 左右,缩短到 1s 左右。

但整体成果还不太现实。

5. 第三次优化

通过后面的两次优化,批量查问评估接口性能有一些晋升,但耗时还是大于 1s。

呈现这个问题的根本原因是:一次性查问的数据太多。

那么,咱们为什么不限度一下,每次查问的记录条数呢?

第三次优化,限度一次性查问的记录条数。其实之前也做了限度,不过最大是 2000 条记录,从目前看成果不好。

限度该接口一次只能查 200 条记录,如果超过 200 条则会报错提醒。

如果间接对该接口做限度,则可能会导致业务零碎出现异常。

为了防止这种状况的产生,必须跟业务零碎团队一起讨论一下优化计划。

次要有上面两个计划:

5.1 前端做分页

在结算单列表页中,每个结算单默认只展现 1 个订单,多余的分页查问。

这样的话,如果依照每页最大 100 条记录计算的话,结算单和订单最多一次只能查问 200 条记录。

这就须要业务零碎的前端做分页性能,同时后端接口要调整反对分页查问。

但目前现状是前端没有多余开发资源。

因为人手不足的起因,这套计划目前只能临时搁置。

5.2 分批调用接口

业务零碎后端之前是一次性调用评估查问接口,当初改成分批调用。

比方:之前查问 500 条记录,业务零碎只调用一次查问接口。

当初改成业务零碎每次只查 100 条记录,分 5 批调用,总共也是查问 500 条记录。

这样不是变慢了吗?

答:如果那 5 批调用评估查问接口的操作,是在 for 循环中单线程程序的,整体耗时当然可能会变慢。

但业务零碎也能够改成多线程调用,只需最终汇总后果即可。

此时,有人可能会问题:在评估查问接口的服务器多线程调用,跟在其余业务零碎中多线程调用不是一回事?

还不如把批量评估查问接口的服务器中,线程池的最大线程数调大一点?

显然你疏忽了一件事:线上利用个别不会被部署成单点。绝大多数状况下,为了防止因为服务器挂了,造成单点故障,根本会部署至多 2 个节点。这样即便一个节点挂了,整个利用也能失常拜访。

当然也可能会呈现这种状况:如果挂了一个节点,另外一个节点可能因为拜访的流量太大了,扛不住压力,也可能因而挂掉。

换句话说,通过业务零碎中的多线程调用接口,能够将拜访接口的流量负载平衡到不同的节点上。

他们也用 8 个线程,将数据分批,每批 100 条记录,最初将后果汇总。

通过这次优化,接口性能再次晋升了 1 倍。

从 1s 左右,缩短到小于 500ms。

舒适揭示一下,无论是在批量查问评估接口查询数据库,还是在业务零碎中调用批量查问评估接口,应用多线程调用,都只是一个长期计划,并不完满。

这样做的起因次要是为了先疾速解决问题,因为这种计划改变是最小的。

要从根本上解决问题,须要从新设计这一套性能,须要批改表构造,甚至可能须要批改业务流程。但因为牵涉到多条业务线,多个业务零碎,只能排期缓缓做了。

正文完
 0