從20s優化到500ms,我用了這三招
前言
介面效能問題,對於從事後端開發的同學來說,是一個繞不開的話題。想要優化一個介面的效能,需要從多個方面著手。
其實,我之前也寫過一篇介面效能優化相關的文章《聊聊介面效能優化的11個小技巧》,發表之後在全網廣受好評,感興趣的小夥們可以仔細看看。
本文將會接著介面效能優化這個話題,從實戰的角度出發,聊聊我是如何優化一個慢查詢介面的。
上週我優化了一下線上的批量評分查詢介面,將介面效能從最初的20s
,優化到目前的500ms
以內。
總體來說,用三招就搞定了。
到底經歷了什麼?
1. 案發現場
我們每天早上上班前,都會收到一封線上慢查詢介面彙總郵件,郵件中會展示介面地址
、呼叫次數
、最大耗時
、平均耗時
和traceId
等資訊。
我看到其中有一個批量評分查詢介面,最大耗時達到了20s
,平均耗時也有2s
。
用skywalking
檢視該介面的呼叫資訊,發現絕大數情況下,該介面響應還是比較快的,大部分情況都是500ms左右就能返回,但也有少部分超過了20s的請求。
這個現象就非常奇怪了。
莫非跟資料有關?
比如:要查某一個組織的資料,是非常快的。但如果要查平臺,即組織的根節點,這種情況下,需要查詢的資料量非常大,介面響應就可能會非常慢。
但事實證明不是這個原因。
很快有個同事給出了答案。
他們在結算單列表頁面中,批量請求了這個介面,但他傳參的資料量非常大。
怎麼回事呢?
當初說的需求是這個介面給分頁的列表頁面呼叫,每頁大小有:10、20、30、50、100,使用者可以選擇。
換句話說,呼叫批量評價查詢介面,一次性最多可以查詢100條記錄。
但實際情況是:結算單列表頁面還包含了很多訂單。基本上每一個結算單,都有多個訂單。呼叫批量評價查詢介面時,需要把結算單和訂單的資料合併到一起。
這樣導致的結果是:呼叫批量評價查詢介面時,一次性傳入的引數非常多,入參list中包含幾百、甚至幾千條資料都有可能。
2. 現狀
如果一次性傳入幾百或者幾千個id,批量查詢資料還好,可以走主鍵索引,查詢效率也不至於太差。
但那個批量評分查詢介面,邏輯不簡單。
虛擬碼如下:
```java
public List
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;
} ```
其實在真實場景中,程式碼比這個複雜很多,這裡為了給大家演示,簡化了一下。
最關鍵的地方有兩點: 1. 在介面中遠端呼叫了另外一個介面 2. 需要在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語句會非常長,效能也會很差。
其實還有一種寫法:
sql
where (a,b) in ((1,2),(1,3)...)
不過這種sql,如果一次性查詢的資料量太多的話,效能也不太好。
居然沒法改成批量查詢,就只能優化單條查詢sql的執行效率了。
首先從索引
入手,因為改造成本最低。
第一次優化是
優化索引
。
評價表之前建立一個business_id欄位的普通索引
,但是從目前來看效率不太理想。
由於我果斷的加了聯合索引
:
sql
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
非常合適。
程式碼調整為:
java
CompletableFuture[] futureArray = dataList.stream()
.map(data -> CompletableFuture
.supplyAsync(() -> query(data), asyncExecutor)
.whenComplete((result, th) -> {
})).toArray(CompletableFuture[]::new);
CompletableFuture.allOf(futureArray).join();
CompleteFuture
的本質是建立執行緒
執行,為了避免產生太多的執行緒,所以使用執行緒池
是非常有必要的。
優先推薦使用ThreadPoolExecutor
類,我們自定義執行緒池。
具體程式碼如下:
java
ExecutorService threadPool = new ThreadPoolExecutor(
8, //corePoolSize執行緒池中核心執行緒數
10, //maximumPoolSize 執行緒池中最大執行緒數
60, //執行緒池中執行緒的最大空閒時間,超過這個時間空閒執行緒將被回收
TimeUnit.SECONDS,//時間單位
new ArrayBlockingQueue(500), //佇列
new ThreadPoolExecutor.CallerRunsPolicy()); //拒絕策略
也可以使用ThreadPoolTaskExecutor
類建立執行緒池:
```java @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
。
溫馨提醒一下,無論是在批量查詢評價介面查詢資料庫,還是在業務系統中呼叫批量查詢評價介面,使用多執行緒呼叫,都只是一個臨時方案,並不完美。
這樣做的原因主要是為了先快速解決問題,因為這種方案改動是最小的。
要從根本上解決問題,需要重新設計這一套功能,需要修改表結構,甚至可能需要修改業務流程。但由於牽涉到多條業務線,多個業務系統,只能排期慢慢做了。
如果你想了解更多介面優化的小技巧,可以看看我的另一篇文章《聊聊介面效能優化的11個小技巧》。
最後說一句(求關注,別白嫖我)
如果這篇文章對您有所幫助,或者有所啟發的話,幫忙掃描下發二維碼關注一下,您的支援是我堅持寫作最大的動力。
求一鍵三連:點贊、轉發、在看。
關注公眾號:【蘇三說技術】,在公眾號中回覆:面試、程式碼神器、開發手冊、時間管理有超讚的粉絲福利,另外回覆:加群,可以跟很多BAT大廠的前輩交流和學習。
- 快看!這隻貓兩次登上 Github Trending !!!
- 百萬級資料excel匯出功能如何實現?
- SQL為什麼動不動就N百行以K計?
- 一次SpringBoot版本升級,引發的血案
- MYSQL中的14個神仙功能,驚豔到我了!!!
- 瞧瞧別人家的API介面,那叫一個優雅
- 同事吐槽我的介面效能差,原來它是真凶!
- 如何讓JSON跑得更快?
- 糟了,線上服務出現OOM了
- 7000字 24張圖帶你徹底弄懂執行緒池
- 分頁 模糊查詢 有坑!
- 這12款idea外掛,能讓你程式碼飛起來
- 聊聊資料庫建表的15個小技巧
- 明明加了唯一索引,為什麼還是產生了重複資料?
- 明明加了唯一索引,為什麼還是產生了重複資料?
- Java程式碼優化的30個小技巧
- 聊聊Java中程式碼優化的30個小技巧
- 盤點一下,99%的Java程式設計師會踩的坑
- 聊聊spring事務失效的12種場景,太坑了
- 從20s優化到500ms,我用了這三招