從20s優化到500ms,我用了這三招

語言: CN / TW / HK

前言

介面效能問題,對於從事後端開發的同學來說,是一個繞不開的話題。想要優化一個介面的效能,需要從多個方面著手。

其實,我之前也寫過一篇介面效能優化相關的文章《聊聊介面效能優化的11個小技巧》,發表之後在全網廣受好評,感興趣的小夥們可以仔細看看。

本文將會接著介面效能優化這個話題,從實戰的角度出發,聊聊我是如何優化一個慢查詢介面的。

上週我優化了一下線上的批量評分查詢介面,將介面效能從最初的20s,優化到目前的500ms以內。

總體來說,用三招就搞定了。

到底經歷了什麼?

1. 案發現場

我們每天早上上班前,都會收到一封線上慢查詢介面彙總郵件,郵件中會展示介面地址呼叫次數最大耗時平均耗時traceId等資訊。

我看到其中有一個批量評分查詢介面,最大耗時達到了20s,平均耗時也有2s

skywalking檢視該介面的呼叫資訊,發現絕大數情況下,該介面響應還是比較快的,大部分情況都是500ms左右就能返回,但也有少部分超過了20s的請求。

這個現象就非常奇怪了。

莫非跟資料有關?

比如:要查某一個組織的資料,是非常快的。但如果要查平臺,即組織的根節點,這種情況下,需要查詢的資料量非常大,介面響應就可能會非常慢。

但事實證明不是這個原因。

很快有個同事給出了答案。

他們在結算單列表頁面中,批量請求了這個介面,但他傳參的資料量非常大。

怎麼回事呢?

當初說的需求是這個介面給分頁的列表頁面呼叫,每頁大小有:10、20、30、50、100,使用者可以選擇。

換句話說,呼叫批量評價查詢介面,一次性最多可以查詢100條記錄。

但實際情況是:結算單列表頁面還包含了很多訂單。基本上每一個結算單,都有多個訂單。呼叫批量評價查詢介面時,需要把結算單和訂單的資料合併到一起。

這樣導致的結果是:呼叫批量評價查詢介面時,一次性傳入的引數非常多,入參list中包含幾百、甚至幾千條資料都有可能。

2. 現狀

如果一次性傳入幾百或者幾千個id,批量查詢資料還好,可以走主鍵索引,查詢效率也不至於太差。

但那個批量評分查詢介面,邏輯不簡單。

虛擬碼如下: ```java 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<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_codecategory_idbusiness_idbusiness_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大廠的前輩交流和學習。