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

  • 2020 年 5 月 30 日
  • 筆記

前言

最近對外介面偶現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前查詢一次），如下偽程式碼：


punlic 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里滴哈

//github.com/whx123/JavaHome

公眾號

  • 歡迎關注我個人公眾號，交個朋友，一起學習哈~

VirMach 便宜 VPS

QNews

QNews