hello，大家好，我是張張，「架構精進之路」公号作者。
一、背景
針對老項目，去年做了許多降本增效的事情，其中發現最多的就是接口耗時過長的問題，就集中搞了一次接口性能優化。本文将給小夥伴們分享一下接口優化的通用方案。
二、接口優化方案總結
1.批處理
批量思想：批量操作資料庫，這個很好了解，我們在循環插入場景的接口中，可以在批處理執行完成後一次性插入或更新資料庫，避免多次IO。
//批量入庫
batchInsert(); 2.異步處理
異步思想：針對耗時比較長且不是結果必須的邏輯，我們可以考慮放到異步執行，這樣能降低接口耗時。
例如一個理财的申購接口，入賬和寫入申購檔案是同步執行的，因為是T+1交易，後面這兩個邏輯其實不是結果必須的，我們并不需要關注它的實時結果，是以我們考慮把入賬和寫入申購檔案改為異步處理。如圖所示：
至于異步的實作方式，可以用線程池，也可以用消息隊列，還可以用一些排程任務架構。
3.空間換時間
一個很好了解的空間換時間的例子是合理使用緩存，針對一些頻繁使用且不頻繁變更的資料，可以提前緩存起來，需要時直接查緩存，避免頻繁地查詢資料庫或者重複計算。
需要注意的事，這裡用了合理二字，因為空間換時間也是一把雙刃劍，需要綜合考慮你的使用場景，畢竟緩存帶來的資料一緻性問題也挺令人頭疼。
這裡的緩存可以是R2M，也可以是本地緩存、memcached，或者Map。
舉一個股票工具的查詢例子：
因為政策輪動的調倉資訊，每周隻更新一次，是以原來的調接口就去查庫的邏輯并不合理，而且拿到調倉資訊後，需要經過複雜計算，最終得出回測收益和跑赢滬深指數這些我們想要的結果。如果我們把查庫操作和計算結果放入緩存，可以節省很多的執行時間。如圖：
4.預處理
也就是預取思想，就是提前要把查詢的資料，提前計算好，放入緩存或者表中的某個字段，用的時候會大幅提高接口性能。跟上面那個例子很像，但是關注點不同。
舉個簡單的例子：理财産品，會有根據淨值計算年化收益率的資料展示需求，利用淨值去套用年化收益率計算公式計算的邏輯我們可以采用預處理，這樣每一次接口調用直接取對應字段就可以了。
5.池化思想
我們都用過資料庫連接配接池，線程池等，這就是池思想的展現，它們解決的問題就是避免重複建立對象或建立連接配接，可以重複利用，避免不必要的損耗，畢竟建立銷毀也會占用時間。
池化思想包含但并不局限于以上兩種，總的來說池化思想的本質是預配置設定與循環使用，明白這個原理後，我們即使是在做一些業務場景的需求時，也可以利用起來。
比如：對象池
6.串行改并行
串行就是，目前執行邏輯必須等上一個執行邏輯結束之後才執行，并行就是兩個執行邏輯互不幹擾，是以并行相對來說就比較節省時間，當然是建立在沒有結果參數依賴的前提下。
比如，理财的持倉資訊展示接口，我們既需要查詢使用者的賬戶資訊，也需要查詢商品資訊和banner位資訊等等來渲染持倉頁，如果是串行，基本上接口耗時就是累加的。如果是并行，接口耗時将大大降低。
如圖：
7.索引
加索引能大大提高資料查詢效率，這個在接口設計之出也會考慮到，這裡不再多贅述，随着需求的疊代，我們重點整理一下索引不生效的一些場景，希望對小夥伴們有所幫助。
具體不生效場景不再一一舉例，後面有時間的話，單獨整理一下。
8.避免大事務
所謂大事務問題，就是運作時間較長的事務，由于事務一緻不送出，會導緻資料庫連接配接被占用，影響到别的請求通路資料庫，影響别的接口性能。
舉個例子：
@Transactional(value = "taskTransactionManager", propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED, rollbackFor = {RuntimeException.class, Exception.class})
public BasicResult purchaseRequest(PurchaseRecord record) {
BasicResult result = new BasicResult();
...
pushRpc.doPush(record);
result.setInfo(ResultInfoEnum.SUCCESS);
return result;
} 是以為避免大事務問題，我們可以通過以下方案規避：
1，RPC調用不放到事務裡面
2，查詢操作盡量放到事務之外
3，事務中避免處理太多資料
9.優化程式結構
程式結構問題一般出現在多次需求疊代後，代碼疊加形成。會造成一些重複查詢、多次建立對象等耗時問題。在多人維護一個項目時比較多見。解決起來也比較簡單，我們需要針對接口整體做重構，評估每個代碼塊的作用和用途，調整執行順序。
10.深分頁問題
深分頁問題比較常見，分頁我們一般最先想到的就是 limit ，為什麼會慢，我們可以看下這個SQL：
select *
from purchase_record
where productCode = 'PA9044' and status=4 and id > 100000
limit 200 這樣優化的好處是命中了主鍵索引，無論多少頁，性能都還不錯，但是局限性是需要一個連續自增的字段
11.SQL優化
sql優化能大幅提高接口的查詢性能，由于本文重點講述接口優化的方案，具體sql優化不再一一列舉，小夥伴們可以結合索引、分頁、等關注點考慮優化方案。
12.鎖粒度避免過粗
鎖一般是為了在高并發場景下保護共享資源采用的一種手段，但是如果鎖的粒度太粗，會很影響接口性能。
關于鎖粒度：就是你要鎖的範圍有多大，不管是synchronized還是redis分布式鎖，隻需要在臨界資源處加鎖即可，不涉及共享資源的，不必要加鎖，就好比你要上衛生間，隻需要把衛生間的門鎖上就可以，不需要把客廳的門也鎖上。
錯誤的加鎖方式：
//非共享資源
private void notShare(){
}
//共享資源
private void share(){
}
private int right(){
notShare();
synchronized (this) {
share();
}
} 三、最後
接口性能問題形成的原因思考
我相信很多接口的效率問題不是一朝一夕形成的，在需求疊代的過程中，為了需求快速上線，采取直接累加代碼的方式去實作功能，這樣會造成以上這些接口性能問題。
變換思路，更高一級思考問題，站在接口設計者的角度去開發需求，會避免很多這樣的問題，也是降本增效的一種行之有效的方式。
以上，共勉！
·END·
希望今天的講解對大家有所幫助，謝謝！
Thanks for reading!
作者：張張，十年研發風雨路，大廠架構師，「架構精進之路」專注架構技術沉澱學習及分享，職業與認知更新，堅持分享接地氣兒的幹貨文章，期待與你一起成長。
關注并私信我回複“01”，送你一份程式員成長進階大禮包，歡迎勾搭。