门户网站的建设思路,网站建立需要多久,淘宝客建设网站首页,WordPress编辑器高亮来源 | 苏三说技术
作者 | 苏三呀 前言
接口性能问题#xff0c;对于从事后端开发的同学来说#xff0c;是一个绕不开的话题。想要优化一个接口的性能#xff0c;需要从多个方面着手。
本文将会围绕接口性能优化这个话题#xff0c;从实战的角度出发#xff0c;聊聊我是…来源 | 苏三说技术
作者 | 苏三呀 前言
接口性能问题对于从事后端开发的同学来说是一个绕不开的话题。想要优化一个接口的性能需要从多个方面着手。
本文将会围绕接口性能优化这个话题从实战的角度出发聊聊我是如何优化一个慢查询接口的。
上周我优化了一下线上的批量评分查询接口将接口性能从最初的20s优化到目前的500ms以内。
总体来说用三招就搞定了。
到底经历了什么 1. 案发现场
我们每天早上上班前都会收到一封线上慢查询接口汇总邮件邮件中会展示接口地址、调用次数、最大耗时、平均耗时和traceId等信息。
我看到其中有一个批量评分查询接口最大耗时达到了20s平均耗时也有2s。
用skywalking查看该接口的调用信息发现绝大多数情况下该接口响应还是比较快的大部分情况都是 500ms 左右就能返回但也有少部分超过了 20s 的请求。
这个现象就非常奇怪了。
莫非跟数据有关
比如要查某一个组织的数据是非常快的。但如果要查平台即组织的根节点这种情况下需要查询的数据量非常大接口响应就可能会非常慢。
但事实证明不是这个原因。
很快有个同事给出了答案。
他们在结算单列表页面中批量请求了这个接口但他传参的数据量非常大。
怎么回事呢
当初说的需求是这个接口给分页的列表页面调用每页大小有10、20、30、50、100用户可以选择。
换句话说调用批量评价查询接口一次性最多可以查询 100 条记录。
但实际情况是结算单列表页面还包含了很多订单。基本上每一个结算单都有多个订单。调用批量评价查询接口时需要把结算单和订单的数据合并到一起。
这样导致的结果是调用批量评价查询接口时一次性传入的参数非常多入参 list 中包含几百、甚至几千条数据都有可能。 2. 现状
如果一次性传入几百或者几千个 id批量查询数据还好可以走主键索引查询效率也不至于太差。
但那个批量评分查询接口逻辑不简单。
伪代码如下
public ListScoreEntity query(ListSearchEntity list) {//结果ListScoreEntity result Lists.newArrayList();//获取组织idListLong orgIds list.stream().map(SearchEntity::getOrgId).collect(Collectors.toList());//通过regin调用远程接口获取组织信息ListOrgEntity 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());ListScoreEntity 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_code001 and category_id123 and business_id111 and business_type1) or (org_code002 and category_id123 and business_id112 and business_type2) or (org_code003 and category_id124 and business_id117 and business_type1)...
不过这种方式会导致 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左右。
但整体效果还不太理想。 3.3 第三次优化
经过前面的两次优化批量查询评价接口性能有一些提升但耗时还是大于 1s。
出现这个问题的根本原因是一次性查询的数据太多。
那么我们为什么不限制一下每次查询的记录条数呢 第三次优化限制一次性查询的记录条数。其实之前也做了限制不过最大是 2000 条记录从目前看效果不好。 限制该接口一次只能查200条记录如果超过200条则会报错提示。
如果直接对该接口做限制则可能会导致业务系统出现异常。
为了避免这种情况的发生必须跟业务系统团队一起讨论一下优化方案。
主要有下面两个方案
3.3.1 前端做分页
在结算单列表页中每个结算单默认只展示 1 个订单多余的分页查询。
这样的话如果按照每页最大 100 条记录计算的话结算单和订单最多一次只能查询 200 条记录。
这就需要业务系统的前端做分页功能同时后端接口要调整支持分页查询。
但目前现状是前端没有多余开发资源。
由于人手不足的原因这套方案目前只能暂时搁置。
3.3.2 分批调用接口
业务系统后端之前是一次性调用评价查询接口现在改成分批调用。
比如之前查询 500 条记录业务系统只调用一次查询接口。
现在改成业务系统每次只查 100 条记录分 5 批调用总共也是查询 500 条记录。
这样不是变慢了吗
答如果那 5 批调用评价查询接口的操作是在 for 循环中单线程顺序的整体耗时当然可能会变慢。
但业务系统也可以改成多线程调用只需最终汇总结果即可。
此时有人可能会问在评价查询接口的服务器多线程调用跟在其他业务系统中多线程调用不是一回事
还不如把批量评价查询接口的服务器中线程池的最大线程数调大一点
显然你忽略了一件事线上应用一般不会被部署成单点。绝大多数情况下为了避免因为服务器挂了造成单点故障基本会部署至少 2 个节点。这样即使一个节点挂了整个应用也能正常访问。 当然也可能会出现这种情况假如挂了一个节点另外一个节点可能因为访问的流量太大了扛不住压力也可能因此挂掉。 换句话说通过业务系统中的多线程调用接口可以将访问接口的流量负载均衡到不同的节点上。
他们也用 8 个线程将数据分批每批 100 条记录最后将结果汇总。
经过这次优化接口性能再次提升了 1 倍。
从1s左右缩短到小于500ms。
4. 总结
温馨提醒一下无论是在批量查询评价接口数据库还是在业务系统中调用批量查询评价接口使用多线程调用都只是一个临时方案并不完美。
这样做的原因主要是为了先快速解决问题因为这种方案改动是最小的。
要从根本上解决问题需要重新设计这一套功能需要修改表结构甚至可能需要修改业务流程。但由于牵涉到多条业务线多个业务系统只能排期慢慢做了。
- END -
