大家好，最近看到京東云的一位大佬分享的介面優化方案，感覺挺不錯的，拿來即用，建議收藏一波或者整理到自己的筆記本中，隨時查閱！
來源：https://toutiao.io/posts/0kwkbbt
下面是正文，
一、背景
針對老專案，去年做了許多降本增效的事情，其中發現最多的就是介面耗時過長的問題，就集中搞了一次介面性能優化，本文將給小伙伴們分享一下介面優化的通用方案，
二、介面優化方案總結
1.批處理
批量思想：批量操作資料庫，這個很好理解，我們在回圈插入場景的介面中，可以在批處理執行完成后一次性插入或更新資料庫，避免多次 IO，
//for回圈單筆入庫
list.stream().forEatch(msg->{
insert();
});
//批量入庫
batchInsert();
2. 異步處理
異步思想：針對耗時比較長且不是結果必須的邏輯，我們可以考慮放到異步執行，這樣能降低介面耗時，
例如一個理財的申購介面，入賬和寫入申購檔案是同步執行的，因為是 T+1 交易，后面這兩個邏輯其實不是結果必須的，我們并不需要關注它的實時結果，所以我們考慮把入賬和寫入申購檔案改為異步處理，如圖所示：
至于異步的實作方式，可以用執行緒池，也可以用訊息佇列，還可以用一些調度任務框架，
推薦一個開源免費的 Spring Boot 最全教程：
https://github.com/javastacks/spring-boot-best-practice
3. 空間換時間
一個很好理解的空間換時間的例子是合理使用快取，針對一些頻繁使用且不頻繁變更的資料，可以提前快取起來，需要時直接查快取，避免頻繁地查詢資料庫或者重復計算，
需要注意的事，這里用了合理二字，因為空間換時間也是一把雙刃劍，需要綜合考慮你的使用場景，畢竟快取帶來的資料一致性問題也挺令人頭疼，
這里的快取可以是 R2M，也可以是本地快取、memcached，或者 Map，
舉一個股票工具的查詢例子：
因為策略輪動的調倉資訊，每周只更新一次，所以原來的調介面就去查庫的邏輯并不合理，而且拿到調倉資訊后，需要經過復雜計算，最終得出回測收益和跑贏滬深指數這些我們想要的結果，如果我們把查庫操作和計算結果放入快取，可以節省很多的執行時間，如圖：
4. 預處理
也就是預取思想，就是提前要把查詢的資料，提前計算好，放入快取或者表中的某個欄位，用的時候會大幅提高介面性能，跟上面那個例子很像，但是關注點不同，
舉個簡單的例子：理財產品，會有根據凈值計算年化收益率的資料展示需求，利用凈值去套用年化收益率計算公式計算的邏輯我們可以采用預處理，這樣每一次介面呼叫直接取對應欄位就可以了，
5. 池化思想
我們都用過資料庫連接池，執行緒池等，這就是池思想的體現，它們解決的問題就是避免重復創建物件或創建連接，可以重復利用，避免不必要的損耗，畢竟創建銷毀也會占用時間，
池化思想包含但并不局限于以上兩種，總的來說池化思想的本質是預分配與回圈使用，明白這個原理后，我們即使是在做一些業務場景的需求時，也可以利用起來，
比如：物件池
6. 串行改并行
串行就是，當前執行邏輯必須等上一個執行邏輯結束之后才執行，并行就是兩個執行邏輯互不干擾，所以并行相對來說就比較節省時間，當然是建立在沒有結果引數依賴的前提下，
比如，理財的持倉資訊展示介面，我們既需要查詢用戶的賬戶資訊，也需要查詢商品資訊和 banner 位資訊等等來渲染持倉頁，如果是串行，基本上介面耗時就是累加的，如果是并行，介面耗時將大大降低，
如圖：
7. 索引
加索引能大大提高資料查詢效率，這個在介面設計之出也會考慮到，這里不再多贅述，隨著需求的迭代，我們重點整理一下索引不生效的一些場景，希望對小伙伴們有所幫助，
具體不生效場景不再一一舉例，后面有時間的話，單獨整理一下，
8. 避免大事務
所謂大事務問題，就是運行時間較長的事務，由于事務一致不提交，會導致資料庫連接被占用，影響到別的請求訪問資料庫，影響別的介面性能，
舉個例子：
@Transactional(value ="https://www.cnblogs.com/javastack/p/taskTransactionManager", propagation =Propagation.REQUIRED, isolation =Isolation.READ_COMMITTED, rollbackFor ={RuntimeException.class,Exception.class})
publicBasicResultpurchaseRequest(PurchaseRecordrecord){
BasicResult result =newBasicResult();
//插入賬戶任務
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_account.type(),TaskEnum.Account_bizType.purchase_request.type()));
//插入同步任務
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.purchase.type()));
//插入影像件上傳任務
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.cert.type()));
result.setInfo(ResultInfoEnum.SUCCESS);
return result;
}
上面這塊代碼主要是申購申請完成后，執行一系列的后續操作，如果現在新增申購完成后，發送 push 通知用戶的需求，很有可能我們會在后面直接追加，如下圖所示：事務中嵌套 RPC 呼叫，即非 DB 操作，這些非 DB 操作如果耗時較大的話，可能會出現大事務問題，大資料引發的問題主要有：死鎖、介面超時、主從延遲等，
@Transactional(value ="https://www.cnblogs.com/javastack/p/taskTransactionManager", propagation =Propagation.REQUIRED, isolation =Isolation.READ_COMMITTED, rollbackFor ={RuntimeException.class,Exception.class})
publicBasicResultpurchaseRequest(PurchaseRecordrecord){
BasicResult result =newBasicResult();
...
pushRpc.doPush(record);
result.setInfo(ResultInfoEnum.SUCCESS);
return result;
}
所以為避免大事務問題，我們可以通過以下方案規避：
1，RPC 呼叫不放到事務里面
2，查詢操作盡量放到事務之外
3，事務中避免處理太多資料
9. 優化程式結構
程式結構問題一般出現在多次需求迭代后，代碼疊加形成，會造成一些重復查詢、多次創建物件等耗時問題，在多人維護一個專案時比較多見，解決起來也比較簡單，我們需要針對介面整體做重構，評估每個代碼塊的作用和用途，調整執行順序，
10. 深分頁問題
深分頁問題比較常見，分頁我們一般最先想到的就是 limit ，為什么會慢，我們可以看下這個 SQL：
select*from purchase_record where productCode ='PA9044'andstatus=4orderby orderTime desclimit100000,200
limit 100000,200 意味著會掃描 100200 行，然后回傳 200 行，丟棄掉前 100000 行，所以執行速度很慢，一般可以采用標簽記錄法來優化，比如：
select*from purchase_record where productCode ='PA9044'andstatus=4and id >100000limit200
這樣優化的好處是命中了主鍵索引，無論多少頁，性能都還不錯，但是局限性是需要一個連續自增的欄位
11.SQL 優化
sql 優化能大幅提高介面的查詢性能，由于本文重點講述介面優化的方案，具體 sql 優化不再一一列舉，小伙伴們可以結合索引、分頁、等關注點考慮優化方案，
12. 鎖粒度避免過粗
鎖一般是為了在高并發場景下保護共享資源采用的一種手段，但是如果鎖的粒度太粗，會很影響介面性能，
關于鎖粒度：就是你要鎖的范圍有多大，不管是 synchronized 還是 redis 分布式鎖，只需要在臨界資源處加鎖即可，不涉及共享資源的，不必要加鎖，就好比你要上衛生間，只需要把衛生間的門鎖上就可以，不需要把客廳的門也鎖上，
錯誤的加鎖方式：
//非共享資源
privatevoidnotShare(){
}
//共享資源
privatevoidshare(){
}
privateintwrong(){
synchronized(this){
share();
notShare();
}
}
正確的加鎖方式：
//非共享資源
privatevoidnotShare(){
}
//共享資源
privatevoidshare(){
}
privateintright(){
notShare();
synchronized(this){
share();
}
}
三、最后
我相信很多介面的效率問題不是一朝一夕形成的，在需求迭代的程序中，為了需求快速上線，采取直接累加代碼的方式去實作功能，這樣會造成以上這些介面性能問題，
變換思路，更高一級思考問題，站在介面設計者的角度去開發需求，會避免很多這樣的問題，也是降本增效的一種行之有效的方式，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/552465.html
標籤：Java
上一篇：Bigdecimal使用
下一篇：返回列表