### 前言 最近對外介面偶現504超時問題，原因是程式碼執行時間過長，超過nginx配置的15秒，然後真槍實彈搞了一次介面效能優化。在這裡結合優化過程，總結了介面優化的八個要點，希望對大家有幫助呀~ - 資料量比較大，批量操作資料入庫 - 耗時操作考慮非同步處理 - 恰當使用快取 - 優化程式邏輯、程式碼 - SQL優化 - 壓縮傳輸內容 - 考慮使用檔案/MQ等其他方式暫存，非同步再落地DB - 跟產品討論需求最恰當，最舒服的實現方式 嘻嘻，先看一下我們對外轉賬介面的大概流程吧  ### 1.資料量比較大，批量操作資料入庫 **優化前：** ``` //for迴圈單筆入庫 for(TransDetail detail:list){ insert(detail); } ``` **優化後：** ``` // 批量入庫,mybatis demo實現 ``` **效能對比：** | 單位（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迴圈，是否重複例項化物件等等，這些適當優化，都是可以讓你的程式碼跑得更快的。 之前我這篇文章，也提了幾個優化點噢，有興趣的朋友可以看一下哈~ [寫程式碼有這些想法，同事才不會認為你是複製貼上程式設計師](https://juejin.im/post/5dfe2e72518825125f39a2de#heading-1) ### 5. 優化你的SQL 很多時候，你的介面效能瓶頸就在SQL這裡，慢查詢需要我們重點關注的點呢。 我們可以通過這些方式優化我們的SQL： - 加索引 - 避免返回不必要的資料 - 優化sql結構 - 分庫分表 - 讀寫分離 有興趣的朋友可以看一下我這篇文章呢，很詳細的SQL優化點： [後端程式設計師必備：書寫高質量SQL的30條建議](https://juejin.im/post/5e624d156fb9a07ca80ab6f2) ### 6.壓縮傳輸內容 壓縮傳輸內容，檔案變得更小，因此傳輸會更快啦。10M頻寬，傳輸10k的報文，一般比傳輸1M的會快呀；打個比喻，一匹千里馬，它馱著一百斤的貨跑得快，還是馱著10斤的貨物跑得快呢？ **解析：** - 如果你的介面效能不好，然後傳輸報文比較大的話，這時候是可以考慮壓縮檔案內容傳輸的，最後優化效果可能很不錯哦~ ### 7. 考慮使用檔案/MQ等其他方式暫存資料，非同步再落地DB 如果資料太大，落地資料庫實在是慢的話，可以考慮先用檔案的方式儲存，或者考慮MQ，先落地，再非同步儲存到資料庫~ > 本次轉賬介面，如果是併發開啟，10個併發度，每個批次1000筆資料，資料庫插入會特別耗時，大概10秒左右，這個跟我們公司的資料庫同步機制有關，併發情況下，因為優先保證同步，所以並行的插入變成序列啦，就很耗時。 **優化前：** 優化前，1000筆先落地DB資料庫，再非同步轉賬，如下：  **優化後：** 先儲存資料到檔案，再非同步下載下來，插入資料庫，如下：  **解析：** - 如果你的耗時瓶頸就在資料庫插入操作這裡了，那就考慮檔案儲存或者MQ或者其他方式暫存吧，檔案儲存資料，對比一下耗時，有時候會有意想不到的效果哦。 ### 8.跟產品討論需求最恰當，最舒服的實現方式 這點個人覺得還是很重要的，有些需求需要好好跟產品溝通的。 > 比如有個使用者連麥列表展示的需求，產品說要展示所有的連麥資訊，如果一個使用者的連麥列表資訊好大，你拉取所有連麥資料回來，介面效能就降下來啦。如果產品打樁分析，會發現，一般使用者看連麥列表，也就看前幾頁~因此，奸笑，哈哈~ 其實，那個超大分頁載入問題也是類似的。即limit +一個超大的數，一般會很慢的~~ ### 總結 本文呢，基於一次對外介面耗時優化的實踐，總結了優化介面效能的八個點，希望對大家日常開發有幫助哦~嘻嘻，有興趣可以逛逛我的github哈，本文會收藏到github裡滴哈 > https://github.com/whx123/JavaHome ### 公眾號  - 歡迎關注我個人公眾號，交個朋友，一起學