摘要

常見性能優(yōu)化思路

從理論上分析，性能優(yōu)化手段通常有

批量

1. 請求數(shù)據(jù)庫，我們一般會用in,提高數(shù)據(jù)庫查詢效率
2. 調(diào)用外部服務(wù)，我們也需要要求依賴方提供批量接口，避免多次網(wǎng)絡(luò)請求
3. 批量查詢的id數(shù)量也不宜過多

之前在sql IN一文中分析過，IN 的數(shù)量太多時，性能會下降。同樣服務(wù)間調(diào)用，數(shù)據(jù)量過大，帶寬占用大。所以這時候需要分批調(diào)用。

 List res=  Lists.partition(ids, 200).parallelStream()
 .flatMap(batch -> mServiceA.batchGetA(batch).stream())
 .collect(Collectors.toList());

并行/并發(fā)處理，利用多線程可以提高效率

比如接口中需要請求多個外部接口/數(shù)據(jù)庫，相互之間無依賴，因?yàn)檫@種操作都是IO操作，可以由順序執(zhí)行改為并行執(zhí)行，充分利用cpu處理能力,如

CompletableFuture a = CompletableFuture.supplyAsync(() -> mServiceA.getA());
CompletableFuture b = CompletableFuture.supplyAsync(() -> mServiceB.getB());
CompletableFuture.allOf(a,b).join();

異步，非強(qiáng)依賴的調(diào)用可以通過異步化處理

異步，分為讀寫。比如寫是弱依賴，可以用 @Async 或者其他操作。

如果是讀，不是必須的數(shù)據(jù)，也需要加上超時處理,因?yàn)橥獠空{(diào)用有網(wǎng)絡(luò)原因，都是不可靠的

CompletableFuture a = CompletableFuture.supplyAsync(() -> mServiceA.getA());

CompletableFuture b = CompletableFuture.supplyAsync(() -> mServiceB.getB());
try {
    CompletableFuture.allOf(a, b).get(1000, TimeUnit.MILLISECONDS);
} catch (Exception ex) {
    if (!a.isDone()) {
        
    }
    if (!b.isDone()) {
        
    }
}

減少數(shù)據(jù)處理量

eg. 拉取外部數(shù)據(jù)，全量的循環(huán)去拉，增量的使用事件通知機(jī)制，這樣可以減少數(shù)據(jù)處理量

避免深度分頁

數(shù)據(jù)庫的深度分頁性能比較差，需要在業(yè)務(wù)上避免深度分頁

緩存

緩存本質(zhì)上就是從讀取速度快的設(shè)備中直接獲取數(shù)據(jù)。通過空間來換時間。對于DB中的數(shù)據(jù)可以緩存，對于外部服務(wù)的數(shù)據(jù)同樣可以緩存

使用多級緩存，可以最大限度提升性能。

分享文章：API接口性能優(yōu)化總結(jié)
當(dāng)前鏈接：http://uogjgqi.cn/article/ccoooed.html