5個接口性能提升的通用技巧

前言

作為后端開發(fā)人員捅膘，我們總是在編寫各種API溯警，無論是為前端web提供數(shù)據(jù)支持的HTTP REST API ，還是提供內(nèi)部使用的RPC API晾匠。這些API在服務(wù)初期可能表現(xiàn)不錯具壮，但隨著用戶數(shù)量的增長准颓，一開始響應(yīng)很快的API越來越慢，直到用戶抱怨：“你的系統(tǒng)太糟糕了棺妓∪烈眩” 我只是瀏覽網(wǎng)頁。為什么這么慢怜跑？”样勃。這時候你就需要考慮如何優(yōu)化你的API性能了。

要想提高你的API的性能，我們首先要知道哪些問題會導(dǎo)致接口響應(yīng)慢峡眶。API設(shè)計(jì)需要考慮很多方面剧防。開發(fā)語言層面只占一小部分。哪個部分設(shè)計(jì)不好就會成為性能瓶頸辫樱。影響API性能的因素有很多诵姜，總結(jié)如下：

數(shù)據(jù)庫慢查詢
復(fù)雜的業(yè)務(wù)邏輯
糟糕的代碼
資源不足
........

在這篇文章中，我總結(jié)了一些行之有效的API性能優(yōu)化技巧搏熄，希望能給有需要的朋友一些幫助。

歡迎關(guān)注個人公眾號『JAVA旭陽』交流溝通

1. 并發(fā)調(diào)用

假設(shè)我們現(xiàn)在有一個電子商務(wù)系統(tǒng)需要提交訂單暇赤。該功能需要調(diào)用庫存系統(tǒng)進(jìn)行庫存查扣心例，還需要獲取用戶地址信息。最后調(diào)用風(fēng)控系統(tǒng)判斷本次交易無風(fēng)險(xiǎn)鞋囊。這個接口的設(shè)計(jì)大部分可能會把接口設(shè)計(jì)成一個順序執(zhí)行的接口止后。畢竟我們需要獲取到用戶地址信息，完成庫存扣減溜腐，才能進(jìn)行下一步译株。偽代碼如下：

public Boolean submitOrder(orderInfo orderInfo) {

    //check stock
    stockService.check();
    //invoke addressService
    addressService.getByUser();
    //risk control
    riskControlSerivce.check();

    return doSubmitOrder(orderInfo);
}
復(fù)制代碼

如果我們仔細(xì)分析這個函數(shù)，就會發(fā)現(xiàn)幾個方法調(diào)用之間并沒有很強(qiáng)的依賴關(guān)系挺益。而且這三個系統(tǒng)的調(diào)用都比較耗時歉糜。假設(shè)這些系統(tǒng)的調(diào)用耗時分布如下

stockService.check()需要 150 毫秒。
addressService.getByUser()需要 200 毫秒望众。
riskControlSerivce.check()需要 300 毫秒匪补。

如果順序調(diào)用此API，則整個API的執(zhí)行時間為650ms（150ms+200ms+300ms）烂翰。如果能轉(zhuǎn)化為并行調(diào)用夯缺，API的執(zhí)行時間為300ms，性能直接提升50%甘耿。使用并行調(diào)用踊兜，大致代碼如下：

public Boolean submitOrder(orderInfo orderInfo) {

    //check stock
    CompletableFuture<Void> stockFuture = CompletableFuture.supplyAsync(() -> {
        return stockService.check(); 
    }, executor);
    //invoke addressService
    CompletableFuture<Address> addressFuture = CompletableFuture.supplyAsync(() -> {
        return addressService.getByUser();
    }, executor);
    //risk control
    CompletableFuture<Void> riskFuture = CompletableFuture.supplyAsync(() -> {
        return  riskControlSerivce.check();
    }, executor);

    CompletableFuture.allOf(stockFuture, addressFuture, riskFuture);
    stockFuture.get();
    addressFuture.get();
    riskFuture.get();
    return doSubmitOrder(orderInfo);
}
復(fù)制代碼

2. 避免大事務(wù)

所謂大事務(wù)，就是歷經(jīng)時間很長的事務(wù)佳恬。如果使用Spring @Transaction管理事務(wù)捏境，需要注意是否不小心啟動了大事務(wù)。因?yàn)镾pring的事務(wù)管理原理是將多個事務(wù)合并到一個執(zhí)行中毁葱，如果一個API里面有多個數(shù)據(jù)庫讀寫典蝌，而且這個API的并發(fā)訪問量比較高，很可能大事務(wù)會導(dǎo)致太大大量數(shù)據(jù)鎖在數(shù)據(jù)庫中头谜，造成大量阻塞骏掀，數(shù)據(jù)庫連接池連接耗盡。

@Transactional(rollbackFor=Exception.class)
public Boolean submitOrder(orderInfo orderInfo) {

    //check stock
    stockService.check();
    //invoke addressService
    addressService.getByUser();
    //risk control
    riskControlRpcApi.check();

    orderService.insertOrder(orderInfo);
    orderDetailService.insertOrderDetail(orderInfo);

    return true;
}
復(fù)制代碼

相信在很多人寫的業(yè)務(wù)中都出現(xiàn)過這種代碼，遠(yuǎn)程調(diào)用操作截驮，一個非DB操作笑陈，混合在持久層代碼中，這種代碼絕對是一個大事務(wù)葵袭。它不僅需要查詢用戶地址和扣除庫存涵妥，還需要插入訂單數(shù)據(jù)和訂單明細(xì)。這一系列操作需要合并到同一個事務(wù)中坡锡。如果RPC響應(yīng)慢蓬网，當(dāng)前線程會一直占用數(shù)據(jù)庫連接，導(dǎo)致并發(fā)場景下數(shù)據(jù)庫連接耗盡鹉勒。不僅如此帆锋，如果事務(wù)需要回滾，你的API響應(yīng)也會因?yàn)榛貪L慢而變慢禽额。

這個時候就需要考慮減小事務(wù)了锯厢，我們可以把非事務(wù)操作和事務(wù)操作分開，像這樣：

@Autowired
private OrderDaoService orderDaoService;

public Boolean submitOrder(OrderInfo orderInfo) {

    //invoke addressService
    addressService.getByUser();
    //risk control
    riskControlRpcApi.check();
    return orderDaoService.doSubmitOrder(orderInfo);
}

@Service
public class OrderDaoService{

    @Transactional(rollbackFor=Exception.class)
    public Boolean doSubmitOrder(OrderInfo orderInfo) {
        //check stock
        stockService.check();
        orderService.insertOrder(orderInfo);
        orderDetailService.insertOrderDetail(orderInfo);
        return true;
    }
}
復(fù)制代碼

或者脯倒，您可以使用 spring 的編程事務(wù)TransactionTemplate实辑。

@Autowired
private TransactionTemplate transactionTemplate;

public void submitOrder(OrderInfo orderInfo) {

    //invoke addressService
    addressService.getByUser();
    //risk control
    riskControlRpcApi.check();
    return transactionTemplate.execute(()->{
        return doSubmitOrder(orderInfo);
    })
}

public Boolean doSubmitOrder(OrderInfo orderInfo) {
        //check stock
        stockService.check();
        orderService.insertOrder(orderInfo);
        orderDetailService.insertOrderDetail(orderInfo);
        return true;
    }
復(fù)制代碼

3. 添加合適的索引

我們的服務(wù)在運(yùn)行初期，系統(tǒng)需要存儲的數(shù)據(jù)量很小藻丢，可能是數(shù)據(jù)庫沒有加索引來快速存儲和訪問數(shù)據(jù)剪撬。但是隨著業(yè)務(wù)的增長，單表數(shù)據(jù)量不斷增加悠反，數(shù)據(jù)庫的查詢性能變差婿奔。這時候我們應(yīng)該給你的數(shù)據(jù)庫表添加適當(dāng)?shù)乃饕问慎？梢酝ㄟ^命令查看表的索引（這里以MySQL為例）萍摊。

show index from `your_table_name`;
復(fù)制代碼

ALTER TABLE通過命令添加索引。

ALTER TABLE `your_table_name` ADD INDEX index_name(username);
復(fù)制代碼

有時候如叼，即使加了一些索引冰木，數(shù)據(jù)查詢還是很慢。這時候你可以使用explain命令查看執(zhí)行計(jì)劃來判斷你的SQL語句是否命中了索引笼恰。例如:

explain select * from product_info where type=0;
復(fù)制代碼

你會得到一個分析結(jié)果：

image

一般來說踊沸，索引失效有幾種情況：

不滿足最左前綴原則。例如社证，您創(chuàng)建一個組合索引idx(a,b,c)逼龟。但是你的SQL語句是這樣寫的select * from tb1 where b='xxx' and c='xxxx';。
索引列使用算術(shù)運(yùn)算追葡。select * from tb1 where a%10=0;
索引列使用函數(shù)腺律。select * from tb1 where date_format(a,'%m-%d-%Y')='2023-01-02';
like使用關(guān)鍵字的模糊查詢奕短。select * from tb1 where a like '%aaa';
使用not in或not exist關(guān)鍵字。
等等

4. 返回更少的數(shù)據(jù)

如果我們查詢大量符合條件的數(shù)據(jù)匀钧，我們不需要返回所有數(shù)據(jù)翎碑。我們可以通過分頁的方式增量提供數(shù)據(jù)。這樣之斯，我們需要通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)更少日杈，編碼和解碼數(shù)據(jù)的時間更短，API 響應(yīng)更快佑刷。

但是莉擒，傳統(tǒng)的limit offset方法用于 paging( select * from product limit 10000,20)。當(dāng)頁面數(shù)量很大時瘫絮，查詢會越來越慢涨冀。這是因?yàn)槭褂玫脑?code>limit offset是找出10000條數(shù)據(jù)，然后丟棄前面的9980條數(shù)據(jù)檀何。我們可以使用延遲關(guān)聯(lián)來優(yōu)化此 SQL。

select * from product where id in (select id from product limit 10000,20);
復(fù)制代碼

5. 使用緩存

緩存是一種以空間換時間的解決方案廷支。一些用戶經(jīng)常訪問的數(shù)據(jù)直接緩存在內(nèi)存中频鉴。因?yàn)閮?nèi)存的讀取速度遠(yuǎn)快于磁盤IO，所以我們也可以通過適當(dāng)?shù)木彺鎭硖岣逜PI的性能恋拍。簡單的垛孔，我們可以使用Java的HashMap、ConcurrentHashMap施敢，或者caffeine等本地緩存周荐，或者Memcached、Redis等分布式緩存中間件僵娃。

總結(jié)

我在這里列出了五個通用的 API 性能優(yōu)化技巧概作，這些技巧只有在系統(tǒng)有一定的并發(fā)壓力時才有效。如果本文對你有幫助的話默怨，請留下一個贊吧讯榕。