建站
咨詢
售后
建站咨詢
新聞中心
前言
接口性能問題，對于從事后端開發(fā)的同學(xué)來說，是一個繞不開的話題。想要優(yōu)化一個接口的性能，需要從多個方面著手。
成都創(chuàng)新互聯(lián)長期為上千多家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為青陽企業(yè)提供專業(yè)的網(wǎng)站設(shè)計制作、網(wǎng)站建設(shè)，青陽網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
其實，我之前也寫過一篇接口性能優(yōu)化相關(guān)的文章《??聊聊接口性能優(yōu)化的11個小技巧??》，發(fā)表之后在全網(wǎng)廣受好評，感興趣的小伙們可以仔細看看。
本文將會接著接口性能優(yōu)化這個話題，從實戰(zhàn)的角度出發(fā)，聊聊我是如何優(yōu)化一個慢查詢接口的。
上周我優(yōu)化了一下線上的批量評分查詢接口，將接口性能從最初的20s?，優(yōu)化到目前的500ms以內(nèi)。
總體來說，用三招就搞定了。
到底經(jīng)歷了什么？
1. 案發(fā)現(xiàn)場
我們每天早上上班前，都會收到一封線上慢查詢接口匯總郵件，郵件中會展示接口地址、調(diào)用次數(shù)、最大耗時、平均耗時和traceId等信息。
我看到其中有一個批量評分查詢接口，最大耗時達到了20s?，平均耗時也有2s。
用skywalking查看該接口的調(diào)用信息，發(fā)現(xiàn)絕大數(shù)情況下，該接口響應(yīng)還是比較快的，大部分情況都是500s左右就能返回，但也有少部分超過了20s的請求。
這個現(xiàn)象就非常奇怪了。
莫非跟數(shù)據(jù)有關(guān)？
比如：要查某一個組織的數(shù)據(jù)，是非常快的。但如果要查平臺，即組織的根節(jié)點，這種情況下，需要查詢的數(shù)據(jù)量非常大，接口響應(yīng)就可能會非常慢。
但事實證明不是這個原因。
很快有個同事給出了答案。
他們在結(jié)算單列表頁面中，批量請求了這個接口，但他傳參的數(shù)據(jù)量非常大。
怎么回事呢？
當初說的需求是這個接口給分頁的列表頁面調(diào)用，每頁大小有：10、20、30、50、100，用戶可以選擇。
換句話說，調(diào)用批量評價查詢接口，一次性最多可以查詢100條記錄。
但實際情況是：結(jié)算單列表頁面還包含了很多訂單?；旧厦恳粋€結(jié)算單，都有多個訂單。調(diào)用批量評價查詢接口時，需要把結(jié)算單和訂單的數(shù)據(jù)合并到一起。
這樣導(dǎo)致的結(jié)果是：調(diào)用批量評價查詢接口時，一次性傳入的參數(shù)非常多，入?yún)ist中包含幾百、甚至幾千條數(shù)據(jù)都有可能。
2. 現(xiàn)狀
如果一次性傳入幾百或者幾千個id，批量查詢數(shù)據(jù)還好，可以走主鍵索引，查詢效率也不至于太差。
但那個批量評分查詢接口，邏輯不簡單。
偽代碼如下：
public Listquery(List list) {
//結(jié)果
Listresult = Lists.newArrayList();
//獲取組織id
ListorgIds = list.stream().map(SearchEntity::getOrgId).collect(Collectors.toList());
//通過regin調(diào)用遠程接口獲取組織信息
ListorgList = 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());
ListresultList = scoreMapper.queryScore(scoreSearchEntity);
if(CollectionUtils.isNotEmpty(resultList)) {
ScoreEntity scoreEntity = resultList.get(0);
result.add(scoreEntity);
}
}
return result;
}
其實在真實場景中，代碼比這個復(fù)雜很多，這里為了給大家演示，簡化了一下。
最關(guān)鍵的地方有兩點：
- 在接口中遠程調(diào)用了另外一個接口
- 需要在for循環(huán)中查詢數(shù)據(jù)
其中的第1點，即：在接口中遠程調(diào)用了另外一個接口，這個代碼是必須的。
因為如果在評價表?中冗余一個組織code字段，萬一哪天組織表中的組織code有修改，不得不通過某種機制，通知我們同步修改評價表的組織code，不然就會出現(xiàn)數(shù)據(jù)不一致的問題。
很顯然，如果要這樣調(diào)整的話，業(yè)務(wù)流程上要改了，代碼改動有點大。
所以，還是先保持在接口中遠程調(diào)用吧。
這樣看來，可以優(yōu)化的地方只能在：for循環(huán)中查詢數(shù)據(jù)。
3. 第一次優(yōu)化
由于需要在for循環(huán)中，每條記錄都要根據(jù)不同的條件，查詢出想要的數(shù)據(jù)。
由于業(yè)務(wù)系統(tǒng)調(diào)用這個接口時，沒有傳id?，不好在where?條件中用id in (...)，這方式批量查詢數(shù)據(jù)。
其實，有一種辦法不用循環(huán)查詢，一條sql就能搞定需求：使用or?關(guān)鍵字拼接，例如：(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)...
這種方式會導(dǎo)致sql語句會非常長，性能也會很差。
其實還有一種寫法：
where (a,b) in ((1,2),(1,3)...)
不過這種sql，如果一次性查詢的數(shù)據(jù)量太多的話，性能也不太好。
居然沒法改成批量查詢，就只能優(yōu)化單條查詢sql的執(zhí)行效率了。
首先從索引入手，因為改造成本最低。
第一次優(yōu)化是優(yōu)化索引。
評價表之前建立一個business_id字段的普通索引，但是從目前來看效率不太理想。
由于我果斷加了聯(lián)合索引：
alter table user_score add index `un_org_category_business` (`org_code`,`category_id`,`business_id`,`business_type`) USING BTREE;
該聯(lián)合索引由：org_code、category_id、business_id和business_type四個字段組成。
經(jīng)過這次優(yōu)化，效果立竿見影。
批量評價查詢接口最大耗時，從最初的20s?，縮短到了5s左右。
4. 第二次優(yōu)化
由于需要在for循環(huán)中，每條記錄都要根據(jù)不同的條件，查詢出想要的數(shù)據(jù)。
只在一個線程中查詢數(shù)據(jù)，顯然太慢。
那么，為何不能改成多線程調(diào)用？
第二次優(yōu)化，查詢數(shù)據(jù)庫由單線程?改成多線程。
但由于該接口是要將查詢出的所有數(shù)據(jù)，都返回回去的，所以要獲取查詢結(jié)果。
使用多線程調(diào)用，并且要獲取返回值，這種場景使用java8中的CompleteFuture非常合適。
代碼調(diào)整為：
CompletableFuture[] futureArray = dataList.stream()
.map(data -> CompletableFuture
.supplyAsync(() -> query(data), asyncExecutor)
.whenComplete((result, th) -> {
})).toArray(CompletableFuture[]::new);
CompletableFuture.allOf(futureArray).join();
CompleteFuture?的本質(zhì)是創(chuàng)建線程?執(zhí)行，為了避免產(chǎn)生太多的線程，所以使用線程池是非常有必要的。
優(yōu)先推薦使用ThreadPoolExecutor類，我們自定義線程池。
具體代碼如下：
ExecutorService threadPool = new ThreadPoolExecutor(
8, //corePoolSize線程池中核心線程數(shù)
10, //maximumPoolSize 線程池中最大線程數(shù)
60, //線程池中線程的最大空閑時間，超過這個時間空閑線程將被回收
TimeUnit.SECONDS,//時間單位
new ArrayBlockingQueue(500), //隊列
new ThreadPoolExecutor.CallerRunsPolicy()); //拒絕策略
也可以使用ThreadPoolTaskExecutor類創(chuàng)建線程池：
@Configuration
public class ThreadPoolConfig {
/**
* 核心線程數(shù)量，默認1
*/
private int corePoolSize = 8;
/**
* 最大線程數(shù)量，默認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);
// 設(shè)置拒絕策略，直接在execute方法的調(diào)用線程中運行被拒絕的任務(wù)
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
// 執(zhí)行初始化
executor.initialize();
return executor;
}
}
經(jīng)過這次優(yōu)化，接口性能也提升了5倍。
從5s?左右，縮短到1s左右。
但整體效果還不太理想。
5. 第三次優(yōu)化
經(jīng)過前面的兩次優(yōu)化，批量查詢評價接口性能有一些提升，但耗時還是大于1s。
出現(xiàn)這個問題的根本原因是：一次性查詢的數(shù)據(jù)太多。
那么，我們?yōu)槭裁床幌拗埔幌?，每次查詢的記錄條數(shù)呢？
第三次優(yōu)化，限制一次性查詢的記錄條數(shù)。其實之前也做了限制，不過最大是2000條記錄，從目前看效果不好。
限制該接口一次只能查200?條記錄，如果超過200條則會報錯提示。
如果直接對該接口做限制，則可能會導(dǎo)致業(yè)務(wù)系統(tǒng)出現(xiàn)異常。
為了避免這種情況的發(fā)生，必須跟業(yè)務(wù)系統(tǒng)團隊一起討論一下優(yōu)化方案。
主要有下面兩個方案：
5.1 前端做分頁
在結(jié)算單列表頁中，每個結(jié)算單默認只展示1個訂單，多余的分頁查詢。
這樣的話，如果按照每頁最大100條記錄計算的話，結(jié)算單和訂單最多一次只能查詢200條記錄。
這就需要業(yè)務(wù)系統(tǒng)的前端做分頁功能?，同時后端接口要調(diào)整支持分頁查詢。
但目前現(xiàn)狀是前端沒有多余開發(fā)資源。
由于人手不足的原因，這套方案目前只能暫時擱置。
5.2 分批調(diào)用接口
業(yè)務(wù)系統(tǒng)后端之前是一次性?調(diào)用評價查詢接口，現(xiàn)在改成分批調(diào)用。
比如：之前查詢500條記錄，業(yè)務(wù)系統(tǒng)只調(diào)用一次查詢接口。
現(xiàn)在改成業(yè)務(wù)系統(tǒng)每次只查100條記錄，分5批調(diào)用，總共也是查詢500條記錄。
這樣不是變慢了嗎？
答：如果那5批調(diào)用評價查詢接口的操作，是在for循環(huán)中單線程順序的，整體耗時當然可能會變慢。
但業(yè)務(wù)系統(tǒng)也可以改成多線程調(diào)用，只需最終匯總結(jié)果即可。
此時，有人可能會問題：在評價查詢接口的服務(wù)器多線程調(diào)用，跟在其他業(yè)務(wù)系統(tǒng)中多線程調(diào)用不是一回事？
還不如把批量評價查詢接口的服務(wù)器中，線程池的最大線程數(shù)調(diào)大一點？
顯然你忽略了一件事：線上應(yīng)用一般不會被部署成單點。絕大多數(shù)情況下，為了避免因為服務(wù)器掛了，造成單點故障，基本會部署至少2個節(jié)點。這樣即使一個節(jié)點掛了，整個應(yīng)用也能正常訪問。
當然也可能會出現(xiàn)這種情況：假如掛了一個節(jié)點，另外一個節(jié)點可能因為訪問的流量太大了，扛不住壓力，也可能因此掛掉。
換句話說，通過業(yè)務(wù)系統(tǒng)中的多線程調(diào)用接口，可以將訪問接口的流量負載均衡到不同的節(jié)點上。
他們也用8個線程，將數(shù)據(jù)分批，每批100條記錄，最后將結(jié)果匯總。
經(jīng)過這次優(yōu)化，接口性能再次提升了1倍。
從1s?左右，縮短到小于500ms。
溫馨提醒一下，無論是在批量查詢評價接口查詢數(shù)據(jù)庫，還是在業(yè)務(wù)系統(tǒng)中調(diào)用批量查詢評價接口，使用多線程調(diào)用，都只是一個臨時方案，并不完美。
這樣做的原因主要是為了先快速解決問題，因為這種方案改動是最小的。
要從根本上解決問題，需要重新設(shè)計這一套功能，需要修改表結(jié)構(gòu)，甚至可能需要修改業(yè)務(wù)流程。但由于牽涉到多條業(yè)務(wù)線，多個業(yè)務(wù)系統(tǒng)，只能排期慢慢做了。
新聞標題：從20s優(yōu)化到500ms，我用了這三招
標題路徑：http://m.5511xx.com/article/cogcihd.html
