从20s优化到500ms,我用了这三招

 

前言

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

其实,我之前也写过一篇接口性能优化相关的文章《​​聊聊接口性能优化的11个小技巧​​》,发表之后在全网广受好评,感兴趣的小伙们可以仔细看看。

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

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

总体来说,用三招就搞定了。

到底经历了什么?

1. 案发现场

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

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

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

这个现象就非常奇怪了。

莫非跟数据有关?

比如:要查某一个组织的数据,是非常快的。但如果要查平台,即组织的根节点,这种情况下,需要查询的数据量非常大,接口响应就可能会非常慢。

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

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

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

怎么回事呢?

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

换句话说,调用批量评价查询接口,一次性最多可以查询100条记录。

但实际情况是:结算单列表页面还包含了很多订单。基本上每一个结算单,都有多个订单。调用批量评价查询接口时,需要把结算单和订单的数据合并到一起。

这样导致的结果是:调用批量评价查询接口时,一次性传入的参数非常多,入参list中包含几百、甚至几千条数据都有可能。

2. 现状

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

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

伪代码如下:

public List query(List list) {

//结果

List result = Lists.newArrayList();

//获取组织id

List orgIds = list.stream().map(SearchEntity::getOrgId).collect(Collectors.toList());

//通过regin调用远程接口获取组织信息

List 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 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)

THE END
Copyright © 2024 亿华云