[[329031]]

前言

最近對(duì)外接口偶現(xiàn)504超時(shí)問題，原因是代碼執(zhí)行時(shí)間過長，超過nginx配置的15秒，然后真槍實(shí)彈搞了一次接口性能優(yōu)化。在這里結(jié)合優(yōu)化過程，總結(jié)了接口優(yōu)化的八個(gè)要點(diǎn)，希望對(duì)大家有幫助呀~

• 數(shù)據(jù)量比較大，批量操作數(shù)據(jù)入庫
• 耗時(shí)操作考慮異步處理
• 恰當(dāng)使用緩存
• 優(yōu)化程序邏輯、代碼
• SQL優(yōu)化
• 壓縮傳輸內(nèi)容
• 考慮使用文件/MQ等其他方式暫存，異步再落地DB
• 跟產(chǎn)品討論需求最恰當(dāng)，最舒服的實(shí)現(xiàn)方式

嘻嘻，先看一下我們對(duì)外轉(zhuǎn)賬接口的大概流程吧

1.數(shù)據(jù)量比較大，批量操作數(shù)據(jù)入庫

優(yōu)化前：

//for循環(huán)單筆入庫 
for(TransDetail detail:list){ 
  insert(detail);   
} 

優(yōu)化后：

// 批量入庫,mybatis demo實(shí)現(xiàn) 
<insert id="insertBatch" parameterType="java.util.List"> 
insert into trans_detail( id,amount,payer,payee) values 
 <foreach collection="list" item="item" index="index" separator=",">( 
    #{item.id}, #{item.amount}, 
    #{item.payer},#{item.payee} 
  ) 
</foreach> 
</insert> 

性能對(duì)比：

解析

• 批量插入性能更好，更加省時(shí)間，為什么呢?

打個(gè)比喻:假如你需要搬一萬塊磚到樓頂,你有一個(gè)電梯,電梯一次可以放適量的磚(最多放500),你可以選擇一次運(yùn)送一塊磚,也可以一次運(yùn)送500,你覺得哪種方式更方便，時(shí)間消耗更少?

2.耗時(shí)操作考慮異步處理

耗時(shí)操作，考慮用異步處理，這樣可以降低接口耗時(shí)。本次轉(zhuǎn)賬接口優(yōu)化，匹配聯(lián)行號(hào)的操作耗時(shí)有點(diǎn)長，所以優(yōu)化過程把它移到異步處理啦，如下：

優(yōu)化前：

優(yōu)化后

匹配聯(lián)行號(hào)的操作異步處理

性能對(duì)比：

假設(shè)一個(gè)聯(lián)行號(hào)匹配6ms

解析：

• 因?yàn)槁?lián)行號(hào)匹配比較耗時(shí)，放在異步處理的話，同步聯(lián)機(jī)返回可以省掉這部分時(shí)間，大大提升接口性能，并且不會(huì)影響到轉(zhuǎn)賬主流程功能。
• 除了這個(gè)例子，平時(shí)我們類似功能，如用戶注冊成功后，短信郵件通知，也是可以異步處理的，這個(gè)優(yōu)化建議香餑餑的~
• 所以，太耗時(shí)的操作，在不影響主流程功能的情況下，可以考慮開子線程異步處理的啦。

3.恰當(dāng)使用緩存

在適當(dāng)?shù)臉I(yè)務(wù)場景，恰當(dāng)?shù)厥褂镁彺?，是可以大大提高接口性能的。這里的緩存包括：Redis，JVM本地緩存，memcached，或者M(jìn)ap等。

這次轉(zhuǎn)賬接口，使用到緩存啦，舉個(gè)簡單例子吧~

優(yōu)化前

以下是輸入用戶賬號(hào)，匹配聯(lián)行號(hào)的流程圖

優(yōu)化后：

恰當(dāng)使用緩存，代替查詢DB表，流程圖如下：

解析：

• 把熱點(diǎn)數(shù)據(jù)放到緩存，不用每次查詢都去DB拉取，節(jié)省了這部分查SQL的耗時(shí)，美滋滋呀~
• 當(dāng)然，不是什么數(shù)據(jù)都適合放到緩存的哦，訪問比較頻繁的熱點(diǎn)數(shù)據(jù)才考慮緩存起來呢~

4. 優(yōu)化程序邏輯、代碼

優(yōu)化程序邏輯、程序代碼，是可以節(jié)省耗時(shí)的。

我這里就本次的轉(zhuǎn)賬接口優(yōu)化，舉個(gè)例子吧~

優(yōu)化前：

優(yōu)化前，聯(lián)行號(hào)查詢了兩次(檢驗(yàn)參數(shù)一次，插入DB前查詢一次)，如下偽代碼：

punlic void process(Req req){ 
  //檢驗(yàn)參數(shù),包括聯(lián)行號(hào)（前端傳來的payeeBankNo可以為空,但是如果后端沒匹配到，會(huì)拋異常） 
   checkTransParams(Req req); 
   //Save DB 
  saveTransDetail(req);  
} 
 
void checkTransParams（Req req）{ 
    //check Amount,and so on. 
    checkAmount(req.getamount)； 
    //check payeebankNo 
    if（Utils.isEmpty(req.getPayeeBankNo())）{ 
        String payeebankNo = getPayeebankNo(req.getPayeeAccountNo); 
        if(Utils.isEmpty(payeebankNo){ 
            throws Exception(); 
        } 
    } 
} 
 
int saveTransDetail(req){ 
    String payeebankNo = getPayeebankNo(req.getPayeeAccountNo); 
    req.setPayeeBankNo(payeebankNo); 
    insert(req); 
    ... 
} 

優(yōu)化后：

優(yōu)化后，只在校驗(yàn)參數(shù)的時(shí)候插敘一次，然后設(shè)置到對(duì)象里面~ 入庫前就不用再查啦，偽代碼如下：

void checkTransParams（Req req）{ 
    //check Amount,and so on. 
    checkAmount(req.getamount)； 
    //check payeebankNo 
    if（Utils.isEmpty(req.getPayeeBankNo())）{ 
        String payeebankNo = getPayeebankNo(req.getPayeeAccountNo); 
        if(Utils.isEmpty(payeebankNo){ 
            throws Exception(); 
        } 
    } 
    //查詢到有聯(lián)行號(hào)，直接設(shè)置進(jìn)去啦，這樣等下入庫不用再插入多一次 
    req.setPayeeBankNo(payeebankNo); 
} 
 
int saveTransDetail(req){ 
    insert(req); 
    ... 
} 

解析：

• 對(duì)于優(yōu)化程序邏輯、代碼，是可以降低接口耗時(shí)的。以上demo只是一個(gè)很簡單的例子，就是優(yōu)化前payeeBankNo查詢了兩次，但是其實(shí)只查一次就可以了。很多時(shí)候，我們都知道這個(gè)點(diǎn)，但就是到寫代碼的時(shí)候，又忘記了呀~所以，寫代碼的時(shí)候，留點(diǎn)心吧，優(yōu)化你的程序邏輯、代碼哦。
• 除了以上demo這點(diǎn)，還有其它的點(diǎn)，如優(yōu)化if復(fù)雜的邏輯條件，考慮是否可以調(diào)整順序，或者for循環(huán)，是否重復(fù)實(shí)例化對(duì)象等等，這些適當(dāng)優(yōu)化，都是可以讓你的代碼跑得更快的。

5. 優(yōu)化你的SQL

很多時(shí)候，你的接口性能瓶頸就在SQL這里，慢查詢需要我們重點(diǎn)關(guān)注的點(diǎn)呢。

我們可以通過這些方式優(yōu)化我們的SQL：

• 加索引
• 避免返回不必要的數(shù)據(jù)
• 優(yōu)化sql結(jié)構(gòu)
• 分庫分表
• 讀寫分離

6.壓縮傳輸內(nèi)容

壓縮傳輸內(nèi)容，文件變得更小，因此傳輸會(huì)更快啦。10M帶寬，傳輸10k的報(bào)文，一般比傳輸1M的會(huì)快呀;打個(gè)比喻，一匹千里馬，它馱著一百斤的貨跑得快，還是馱著10斤的貨物跑得快呢?

解析：

如果你的接口性能不好，然后傳輸報(bào)文比較大的話，這時(shí)候是可以考慮壓縮文件內(nèi)容傳輸?shù)?，最后?yōu)化效果可能很不錯(cuò)哦~

7. 考慮使用文件/MQ等其他方式暫存數(shù)據(jù)，異步再落地DB

如果數(shù)據(jù)太大，落地?cái)?shù)據(jù)庫實(shí)在是慢的話，可以考慮先用文件的方式保存，或者考慮MQ，先落地，再異步保存到數(shù)據(jù)庫~

本次轉(zhuǎn)賬接口，如果是并發(fā)開啟，10個(gè)并發(fā)度，每個(gè)批次1000筆數(shù)據(jù)，數(shù)據(jù)庫插入會(huì)特別耗時(shí)，大概10秒左右，這個(gè)跟我們公司的數(shù)據(jù)庫同步機(jī)制有關(guān)，并發(fā)情況下，因?yàn)閮?yōu)先保證同步，所以并行的插入變成串行啦，就很耗時(shí)。

優(yōu)化前：

優(yōu)化前，1000筆先落地DB數(shù)據(jù)庫，再異步轉(zhuǎn)賬，如下：

優(yōu)化后：

先保存數(shù)據(jù)到文件，再異步下載下來，插入數(shù)據(jù)庫，如下：

如果你的耗時(shí)瓶頸就在數(shù)據(jù)庫插入操作這里了，那就考慮文件保存或者M(jìn)Q或者其他方式暫存吧，文件保存數(shù)據(jù)，對(duì)比一下耗時(shí)，有時(shí)候會(huì)有意想不到的效果哦。

8.跟產(chǎn)品討論需求最恰當(dāng)，最舒服的實(shí)現(xiàn)方式

這點(diǎn)個(gè)人覺得還是很重要的，有些需求需要好好跟產(chǎn)品溝通的。

比如有個(gè)用戶連麥列表展示的需求，產(chǎn)品說要展示所有的連麥信息，如果一個(gè)用戶的連麥列表信息好大，你拉取所有連麥數(shù)據(jù)回來，接口性能就降下來啦。如果產(chǎn)品打樁分析，會(huì)發(fā)現(xiàn)，一般用戶看連麥列表，也就看前幾頁~因此，奸笑，哈哈~ 其實(shí)，那個(gè)超大分頁加載問題也是類似的。即limit +一個(gè)超大的數(shù)，一般會(huì)很慢的~~

總結(jié)

本文呢，基于一次對(duì)外接口耗時(shí)優(yōu)化的實(shí)踐，總結(jié)了優(yōu)化接口性能的八個(gè)點(diǎn)，希望對(duì)大家日常開發(fā)有幫助哦~嘻嘻。

本文轉(zhuǎn)載自微信公眾號(hào)「 撿田螺的小男孩」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系 撿田螺的小男孩公眾號(hào)。