記一次介面效能優化實踐總結：優化介面效能的八個建議

轉自：撿田螺的小男孩  作者：撿田螺的小男孩

前言

最近對外介面偶現504超時問題，原因是程式碼執行時間過長，超過nginx配置的15秒，然後真槍實彈搞了一次介面效能優化。在這裡結合優化過程，總結了介面優化的八個要點，希望對大家有幫助呀~

• 資料量比較大，批量運算元據入庫

• 耗時操作考慮非同步處理

• 恰當使用快取

• 優化程式邏輯、程式碼

• SQL優化

• 壓縮傳輸內容

• 考慮使用檔案/MQ等其他方式暫存，非同步再落地DB

• 跟產品討論需求最恰當，最舒服的實現方式

嘻嘻，先看一下我們對外轉賬介面的大概流程吧

1.資料量比較大，批量運算元據入庫

優化前：

• 
  

• //for迴圈單筆入庫

• for(TransDetail detail:list){

•     insert(detail);

• }

優化後：

// 批量入庫,mybatis demo實現
<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>

效能對比：

單位（ms）	for迴圈單筆入庫	批量入庫
500條	1432	1153
1000條	1876	1425
解析

• 批量插入效能更好，更加省時間，為什麼呢？

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

2.耗時操作考慮非同步處理

耗時操作，考慮用非同步處理，這樣可以降低介面耗時。本次轉賬介面優化，匹配聯行號的操作耗時有點長，所以優化過程把它移到非同步處理啦，如下：

優化前：

優化後

匹配聯行號的操作非同步處理

效能對比：

假設一個聯行號匹配6ms

	同步	非同步
500條	3000ms	~
1000條	6000ms	~

解析：

• 因為聯行號匹配比較耗時，放在非同步處理的話，同步聯機返回可以省掉這部分時間，大大提升介面效能，並且不會影響到轉賬主流程功能。

• 除了這個例子，平時我們類似功能，如使用者註冊成功後，簡訊郵件通知，也是可以非同步處理的，這個優化建議香餑餑的~

• 所以，太耗時的操作，在不影響主流程功能的情況下，可以考慮開子執行緒非同步處理的啦。

3.恰當使用快取

在適當的業務場景，恰當地使用快取，是可以大大提高介面效能的。這裡的快取包括：Redis，JVM本地快取，memcached，或者Map等。

這次轉賬介面，使用到快取啦，舉個簡單例子吧~

優化前

以下是輸入使用者賬號，匹配聯行號的流程圖

優化後：

恰當使用快取，代替查詢DB表，流程圖如下：

解析：

• 把熱點資料放到快取，不用每次查詢都去DB拉取，節省了這部分查SQL的耗時，美滋滋呀~

• 當然，不是什麼資料都適合放到快取的哦，訪問比較頻繁的熱點資料才考慮快取起來呢~

4. 優化程式邏輯、程式碼

優化程式邏輯、程式程式碼，是可以節省耗時的。

我這裡就本次的轉賬介面優化，舉個例子吧~

優化前：

優化前，聯行號查詢了兩次（檢驗引數一次，插入DB前查詢一次），如下虛擬碼：

public void process(Req req){
  //檢驗引數,包括聯行號（前端傳來的payeeBankNo可以為空,但是如果後端沒匹配到，會拋異常）
   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);
    ...
}


優化後：

優化後，只在校驗引數的時候插敘一次，然後設定到物件裡面~ 入庫前就不用再查啦，虛擬碼如下：

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();
        }
    }
    //查詢到有聯行號，直接設定進去啦，這樣等下入庫不用再插入多一次
    req.setPayeeBankNo(payeebankNo);
}
int saveTransDetail(req){
    insert(req);
    ...
}

解析：

• 對於優化程式邏輯、程式碼，是可以降低介面耗時的。以上demo只是一個很簡單的例子，就是優化前payeeBankNo查詢了兩次，但是其實只查一次就可以了。很多時候，我們都知道這個點，但就是到寫程式碼的時候，又忘記了呀~所以，寫程式碼的時候，留點心吧，優化你的程式邏輯、程式碼哦。

• 除了以上demo這點，還有其它的點，如優化if複雜的邏輯條件，考慮是否可以調整順序，或者for迴圈，是否重複例項化物件等等，這些適當優化，都是可以讓你的程式碼跑得更快的。

之前我這篇文章，也提了幾個優化點噢，有興趣的朋友可以看一下哈~

寫程式碼有這些想法，同事才不會認為你是複製貼上程式設計師

5. 優化你的SQL

很多時候，你的介面效能瓶頸就在SQL這裡，慢查詢需要我們重點關注的點呢。

我們可以通過這些方式優化我們的SQL：

• 加索引

• 避免返回不必要的資料

• 優化sql結構

• 分庫分表

• 讀寫分離

有興趣的朋友可以看一下我這篇文章呢，很詳細的SQL優化點：

後端程式設計師必備：書寫高質量SQL的30條建議

6.壓縮傳輸內容

壓縮傳輸內容，檔案變得更小，因此傳輸會更快啦。10M頻寬，傳輸10k的報文，一般比傳輸1M的會快呀；打個比喻，一匹千里馬，它馱著一百斤的貨跑得快，還是馱著10斤的貨物跑得快呢？

解析：

• 如果你的介面效能不好，然後傳輸報文比較大的話，這時候是可以考慮壓縮檔案內容傳輸的，最後優化效果可能很不錯哦~

7. 考慮使用檔案/MQ等其他方式暫存資料，非同步再落地DB

如果資料太大，落地資料庫實在是慢的話，可以考慮先用檔案的方式儲存，或者考慮MQ，先落地，再非同步儲存到資料庫~

本次轉賬介面，如果是併發開啟，10個併發度，每個批次1000筆資料，資料庫插入會特別耗時，大概10秒左右，這個跟我們公司的資料庫同步機制有關，併發情況下，因為優先保證同步，所以並行的插入變成序列啦，就很耗時。

優化前：

優化前，1000筆先落地DB資料庫，再非同步轉賬，如下：

優化後：

先儲存資料到檔案，再非同步下載下來，插入資料庫，如下：

解析：

• 如果你的耗時瓶頸就在資料庫插入操作這裡了，那就考慮檔案儲存或者MQ或者其他方式暫存吧，檔案儲存資料，對比一下耗時，有時候會有意想不到的效果哦。

8.跟產品討論需求最恰當，最舒服的實現方式

這點個人覺得還是很重要的，有些需求需要好好跟產品溝通的。

比如有個使用者連麥列表展示的需求，產品說要展示所有的連麥資訊，如果一個使用者的連麥列表資訊好大，你拉取所有連麥資料回來，介面效能就降下來啦。如果產品打樁分析，會發現，一般使用者看連麥列表，也就看前幾頁~因此，奸笑，哈哈~ 其實，那個超大分頁載入問題也是類似的。即limit +一個超大的數，一般會很慢的~~

總結

本文呢，基於一次對外介面耗時優化的實踐，總結了優化介面效能的八個點，希望對大家日常開發有幫助哦~嘻嘻，有興趣可以逛逛我的github哈，本文會收藏到github裡滴哈 、https://github.com/whx123/JavaHom

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31561268/viewspace-2696801/，如需轉載，請註明出處，否則將追究法律責任。