来源 | 苏三说技术

作者 | 苏三呀

前言

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

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

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

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

到底经历了什么？

1. 案发现场

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

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

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

这个现象就非常奇怪了。

莫非跟数据有关？

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

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

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

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

怎么回事呢？

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

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

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

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

2. 现状

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

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

伪代码如下：

public List<ScoreEntity> query(List<SearchEntity> list) {//结果List<ScoreEntity> result = Lists.newArrayList();//获取组织idList<Long> orgIds = list.stream().map(SearchEntity::getOrgId).collect(Collectors.toList());//通过regin调用远程接口获取组织信息List<OrgEntity> orgList = feginClient.getOrgByIds(orgIds);for(SearchEntity entity : list) {//通过组织id找组织codeString 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.优化过程

3. 1 第一次优化

由于需要在 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左右。

3.2 第二次优化

只在一个线程中查询数据，显然太慢。

那么，为何不能改成多线程调用？

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

但由于该接口是要将查询出的所有数据都返回回去的，所以要获取查询结果。

使用多线程调用，并且要获取返回值，这种场景使用 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左右。

但整体效果还不太理想。