※推薦台中搬家公司優質服務,可到府估價
台中搬鋼琴,台中金庫搬運,中部廢棄物處理,南投縣搬家公司,好幫手搬家,西屯區搬家
前言
最近對外接口偶現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里滴哈
https://github.com/whx123/JavaHome
公眾號
- 歡迎關注我個人公眾號，交個朋友，一起學習哈~
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
擁有後台管理系統的網站，將擁有強大的資料管理與更新功能，幫助您隨時新增網站的內容並節省網站開發的成本。
Orignal From: 記一次接口性能優化實踐總結：優化接口性能的八個建議_台中搬家公司
留言
張貼留言