大家好加酵，最近看到京東云的一位大佬分享的接口優(yōu)化方案猪腕，感覺挺不錯(cuò)的，拿來即用亚亲。建議收藏一波或者整理到自己的筆記本中腐缤，隨時(shí)查閱岭粤！
下面是正文。
一巾兆、背景
針對(duì)老項(xiàng)目偿渡，去年做了許多降本增效的事情，其中發(fā)現(xiàn)最多的就是接口耗時(shí)過長的問題吉拳，就集中搞了一次接口性能優(yōu)化留攒。本文將給小伙伴們分享一下接口優(yōu)化的通用方案嫉嘀。
二剪侮、接口優(yōu)化方案總結(jié)
1.批處理
批量思想：批量操作數(shù)據(jù)庫洛退，這個(gè)很好理解兵怯，我們?cè)谘h(huán)插入場景的接口中腔剂，可以在批處理執(zhí)行完成后一次性插入或更新數(shù)據(jù)庫掸犬，避免多次 IO。
//for循環(huán)單筆入庫
list.stream().forEatch(
msg->{
insert();
});
//批量入庫
batchInsert();
2. 異步處理
異步思想：針對(duì)耗時(shí)比較長且不是結(jié)果必須的邏輯宙攻，我們可以考慮放到異步執(zhí)行胜茧，這樣能降低接口耗時(shí)呻顽。
例如一個(gè)理財(cái)?shù)纳曩徑涌冢?strong>入賬和寫入申購文件是同步執(zhí)行的丹墨，因?yàn)槭?T+1 交易贩挣，后面這兩個(gè)邏輯其實(shí)不是結(jié)果必須的，我們并不需要關(guān)注它的實(shí)時(shí)結(jié)果卵迂，所以我們考慮把入賬和寫入申購文件改為異步處理绒净。如圖所示：
至于異步的實(shí)現(xiàn)方式挂疆，可以用線程池缤言，也可以用消息隊(duì)列，還可以用一些調(diào)度任務(wù)框架庆揩。
3. 空間換時(shí)間
一個(gè)很好理解的空間換時(shí)間的例子是合理使用緩存，針對(duì)一些頻繁使用且不頻繁變更的數(shù)據(jù)犬性，可以提前緩存起來乒裆，需要時(shí)直接查緩存推励，避免頻繁地查詢數(shù)據(jù)庫或者重復(fù)計(jì)算验辞。
需要注意的事，這里用了合理二字杆怕，因?yàn)榭臻g換時(shí)間也是一把雙刃劍壳贪，需要綜合考慮你的使用場景违施，畢竟緩存帶來的數(shù)據(jù)一致性問題也挺令人頭疼。
這里的緩存可以是 R2M留潦，也可以是本地緩存辣往、memcached站削，或者 Map。
舉一個(gè)股票工具的查詢例子：
因?yàn)椴呗暂唲?dòng)的調(diào)倉信息屹堰，每周只更新一次街氢，所以原來的調(diào)接口就去查庫的邏輯并不合理珊肃，而且拿到調(diào)倉信息后馅笙，需要經(jīng)過復(fù)雜計(jì)算董习，最終得出回測收益和跑贏滬深指數(shù)這些我們想要的結(jié)果爱只。如果我們把查庫操作和計(jì)算結(jié)果放入緩存恬试，可以節(jié)省很多的執(zhí)行時(shí)間。如圖：
4. 預(yù)處理
也就是預(yù)取思想，就是提前要把查詢的數(shù)據(jù)幻馁，提前計(jì)算好仗嗦，放入緩存或者表中的某個(gè)字段，用的時(shí)候會(huì)大幅提高接口性能吏祸。跟上面那個(gè)例子很像，但是關(guān)注點(diǎn)不同蹈矮。
舉個(gè)簡單的例子：理財(cái)產(chǎn)品，會(huì)有根據(jù)凈值計(jì)算年化收益率的數(shù)據(jù)展示需求蝠咆，利用凈值去套用年化收益率計(jì)算公式計(jì)算的邏輯我們可以采用預(yù)處理北滥，這樣每一次接口調(diào)用直接取對(duì)應(yīng)字段就可以了再芋。
5. 池化思想
我們都用過數(shù)據(jù)庫連接池，線程池等鉴逞，這就是池思想的體現(xiàn)构捡，它們解決的問題就是避免重復(fù)創(chuàng)建對(duì)象或創(chuàng)建連接，可以重復(fù)利用滑凉，避免不必要的損耗譬涡，畢竟創(chuàng)建銷毀也會(huì)占用時(shí)間啥辨。
池化思想包含但并不局限于以上兩種溉知，總的來說池化思想的本質(zhì)是預(yù)分配與循環(huán)使用，明白這個(gè)原理后舌劳，我們即使是在做一些業(yè)務(wù)場景的需求時(shí)甚淡，也可以利用起來捅厂。
比如：對(duì)象池
6. 串行改并行
串行就是焙贷，當(dāng)前執(zhí)行邏輯必須等上一個(gè)執(zhí)行邏輯結(jié)束之后才執(zhí)行，并行就是兩個(gè)執(zhí)行邏輯互不干擾啡彬，所以并行相對(duì)來說就比較節(jié)省時(shí)間庶灿，當(dāng)然是建立在沒有結(jié)果參數(shù)依賴的前提下吃衅。
比如捐晶，理財(cái)?shù)某謧}信息展示接口，我們既需要查詢用戶的賬戶信息山上，也需要查詢商品信息和 banner 位信息等等來渲染持倉頁佩憾，如果是串行，基本上接口耗時(shí)就是累加的楞黄。如果是并行抡驼，接口耗時(shí)將大大降低致盟。
如圖：
7. 索引
加索引能大大提高數(shù)據(jù)查詢效率馏锡，這個(gè)在接口設(shè)計(jì)之出也會(huì)考慮到杯道，這里不再多贅述，隨著需求的迭代萎庭，我們重點(diǎn)整理一下索引不生效的一些場景擎椰，希望對(duì)小伙伴們有所幫助创肥。
具體不生效場景不再一一舉例叹侄，后面有時(shí)間的話昨登，單獨(dú)整理一下丰辣。
8. 避免大事務(wù)
所謂大事務(wù)問題，就是運(yùn)行時(shí)間較長的事務(wù)胚想，由于事務(wù)一致不提交芽隆，會(huì)導(dǎo)致數(shù)據(jù)庫連接被占用胚吁，影響到別的請(qǐng)求訪問數(shù)據(jù)庫腕扶，影響別的接口性能。
舉個(gè)例子：
@Transactional(value ="taskTransactionManager", propagation =Propagation.REQUIRED, isolation =Isolation.READ_COMMITTED, rollbackFor ={RuntimeException.class,Exception.class})
publicBasicResultpurchaseRequest(PurchaseRecordrecord){
BasicResult result =newBasicResult();
//插入賬戶任務(wù)
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_account.type(),TaskEnum.Account_bizType.purchase_request.type()));
//插入同步任務(wù)
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.purchase.type()));
//插入影像件上傳任務(wù)
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.cert.type()));
result.setInfo(ResultInfoEnum.SUCCESS);
return result;
}
上面這塊代碼主要是申購申請(qǐng)完成后，執(zhí)行一系列的后續(xù)操作进肯，如果現(xiàn)在新增申購?fù)瓿珊竺弈ィl(fā)送 push 通知用戶的需求乘瓤。很有可能我們會(huì)在后面直接追加衙傀，如下圖所示：事務(wù)中嵌套 RPC 調(diào)用抬吟，即非 DB 操作，這些非 DB 操作如果耗時(shí)較大的話统抬，可能會(huì)出現(xiàn)大事務(wù)問題火本。大數(shù)據(jù)引發(fā)的問題主要有：死鎖、接口超時(shí)聪建、主從延遲等钙畔。
@Transactional(value ="taskTransactionManager", propagation =Propagation.REQUIRED, isolation =Isolation.READ_COMMITTED, rollbackFor ={RuntimeException.class,Exception.class})
publicBasicResultpurchaseRequest(PurchaseRecordrecord){
BasicResult result =newBasicResult();
//插入賬戶任務(wù)
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_account.type(),TaskEnum.Account_bizType.purchase_request.type()));
//插入同步任務(wù)
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.purchase.type()));
//插入影像件上傳任務(wù)
taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.cert.type()));
result.setInfo(ResultInfoEnum.SUCCESS);
return result;
}
所以為避免大事務(wù)問題，我們可以通過以下方案規(guī)避：
1金麸，RPC 調(diào)用不放到事務(wù)里面
2擎析，查詢操作盡量放到事務(wù)之外
3，事務(wù)中避免處理太多數(shù)據(jù)
9. 優(yōu)化程序結(jié)構(gòu)
程序結(jié)構(gòu)問題一般出現(xiàn)在多次需求迭代后揍魂，代碼疊加形成桨醋。會(huì)造成一些重復(fù)查詢、多次創(chuàng)建對(duì)象等耗時(shí)問題现斋。在多人維護(hù)一個(gè)項(xiàng)目時(shí)比較多見喜最。解決起來也比較簡單，我們需要針對(duì)接口整體做重構(gòu)步责，評(píng)估每個(gè)代碼塊的作用和用途返顺，調(diào)整執(zhí)行順序。
10. 深分頁問題
深分頁問題比較常見蔓肯，分頁我們一般最先想到的就是 limit 遂鹊，為什么會(huì)慢，我們可以看下這個(gè) SQL：
select * from
purchase_record
where
productCode ='PA9044'
and status=4
order by orderTime desc
limit 100000,200
limit 100000,200 意味著會(huì)掃描 100200 行蔗包，然后返回 200 行秉扑，丟棄掉前 100000 行。所以執(zhí)行速度很慢调限。一般可以采用標(biāo)簽記錄法來優(yōu)化舟陆，比如：
select * from purchase_record where productCode ='PA9044' and status=4 and id > 100000 limit 200
這樣優(yōu)化的好處是命中了主鍵索引，無論多少頁耻矮，性能都還不錯(cuò)秦躯，但是局限性是需要一個(gè)連續(xù)自增的字段
11.SQL 優(yōu)化
sql 優(yōu)化能大幅提高接口的查詢性能，由于本文重點(diǎn)講述接口優(yōu)化的方案裆装，具體 sql 優(yōu)化不再一一列舉踱承，小伙伴們可以結(jié)合索引、分頁哨免、等關(guān)注點(diǎn)考慮優(yōu)化方案茎活。
12. 鎖粒度避免過粗
鎖一般是為了在高并發(fā)場景下保護(hù)共享資源采用的一種手段，但是如果鎖的粒度太粗琢唾，會(huì)很影響接口性能载荔。
關(guān)于鎖粒度：就是你要鎖的范圍有多大，不管是 synchronized 還是 redis 分布式鎖采桃，只需要在臨界資源處加鎖即可懒熙，不涉及共享資源的，不必要加鎖普办，就好比你要上衛(wèi)生間煌珊，只需要把衛(wèi)生間的門鎖上就可以，不需要把客廳的門也鎖上泌豆。
錯(cuò)誤的加鎖方式：
//非共享資源
privatevoidnotShare(){
}
//共享資源privatevoidshare(){
}
privateintwrong(){
synchronized(this){
share();
notShare();
}}
正確的加鎖方式：
//非共享資源
privatevoidnotShare(){
}
//共享資源
privatevoidshare(){
}
privateintright(){
notShare();
synchronized(this){
share();
}
}
三、最后
我相信很多接口的效率問題不是一朝一夕形成的吏饿，在需求迭代的過程中踪危，為了需求快速上線蔬浙，采取直接累加代碼的方式去實(shí)現(xiàn)功能，這樣會(huì)造成以上這些接口性能問題贞远。
變換思路畴博，更高一級(jí)思考問題，站在接口設(shè)計(jì)者的角度去開發(fā)需求蓝仲，會(huì)避免很多這樣的問題俱病，也是降本增效的一種行之有效的方式。
