針對(duì)老項(xiàng)目，去年做了許多降本增效的事情，其中發(fā)現(xiàn)最多的就是接口耗時(shí)過(guò)長(zhǎng)的問(wèn)題，就集中搞了一次接口性能優(yōu)化。本文將給小伙伴們分享一下接口優(yōu)化的通用方案。

?

一、接口優(yōu)化方案總結(jié)

1.批處理

批量思想：批量操作數(shù)據(jù)庫(kù)，這個(gè)很好理解，我們?cè)谘h(huán)插入場(chǎng)景的接口中，可以在批處理執(zhí)行完成后一次性插入或更新數(shù)據(jù)庫(kù)，避免多次IO。

//批量入庫(kù) batchInsert();

2.異步處理

異步思想：針對(duì)耗時(shí)比較長(zhǎng)且不是結(jié)果必須的邏輯，我們可以考慮放到異步執(zhí)行，這樣能降低接口耗時(shí)。

例如一個(gè)理財(cái)?shù)纳曩?gòu)接口，入賬和寫(xiě)入申購(gòu)文件是同步執(zhí)行的，因?yàn)槭荰+1交易，后面這兩個(gè)邏輯其實(shí)不是結(jié)果必須的，我們并不需要關(guān)注它的實(shí)時(shí)結(jié)果，所以我們考慮把入賬和寫(xiě)入申購(gòu)文件改為異步處理。如圖所示：

?

至于異步的實(shí)現(xiàn)方式，可以用線(xiàn)程池，也可以用消息隊(duì)列，還可以用一些調(diào)度任務(wù)框架。

3.空間換時(shí)間 （緩存）

一個(gè)很好理解的空間換時(shí)間的例子是合理使用緩存，針對(duì)一些頻繁使用且不頻繁變更的數(shù)據(jù)，可以提前緩存起來(lái)，需要時(shí)直接查緩存，避免頻繁地查詢(xún)數(shù)據(jù)庫(kù)或者重復(fù)計(jì)算。

需要注意的事，這里用了合理二字，因?yàn)榭臻g換時(shí)間也是一把雙刃劍，需要綜合考慮你的使用場(chǎng)景，畢竟緩存帶來(lái)的數(shù)據(jù)一致性問(wèn)題也挺令人頭疼。

這里的緩存可以是R2M，也可以是本地緩存、memcached，或者M(jìn)ap。

舉一個(gè)股票工具的查詢(xún)例子：

因?yàn)椴呗暂唲?dòng)的調(diào)倉(cāng)信息，每周只更新一次，所以原來(lái)的調(diào)接口就去查庫(kù)的邏輯并不合理，而且拿到調(diào)倉(cāng)信息后，需要經(jīng)過(guò)復(fù)雜計(jì)算，最終得出回測(cè)收益和跑贏滬深指數(shù)這些我們想要的結(jié)果。如果我們把查庫(kù)操作和計(jì)算結(jié)果放入緩存，可以節(jié)省很多的執(zhí)行時(shí)間。如圖：

?

4.預(yù)處理

也就是預(yù)取思想，就是提前要把查詢(xún)的數(shù)據(jù)，提前計(jì)算好，放入緩存或者表中的某個(gè)字段，用的時(shí)候會(huì)大幅提高接口性能。跟上面那個(gè)例子很像，但是關(guān)注點(diǎn)不同。

舉個(gè)簡(jiǎn)單的例子：理財(cái)產(chǎn)品，會(huì)有根據(jù)凈值計(jì)算年化收益率的數(shù)據(jù)展示需求，利用凈值去套用年化收益率計(jì)算公式計(jì)算的邏輯我們可以采用預(yù)處理，這樣每一次接口調(diào)用直接取對(duì)應(yīng)字段就可以了。

5.池化思想

我們都用過(guò)數(shù)據(jù)庫(kù)連接池，線(xiàn)程池等，這就是池思想的體現(xiàn)，它們解決的問(wèn)題就是避免重復(fù)創(chuàng)建對(duì)象或創(chuàng)建連接，可以重復(fù)利用，避免不必要的損耗，畢竟創(chuàng)建銷(xiāo)毀也會(huì)占用時(shí)間。

池化思想包含但并不局限于以上兩種，總的來(lái)說(shuō)池化思想的本質(zhì)是預(yù)分配與循環(huán)使用，明白這個(gè)原理后，我們即使是在做一些業(yè)務(wù)場(chǎng)景的需求時(shí)，也可以利用起來(lái)。

比如：對(duì)象池

6.串行改并行

串行就是，當(dāng)前執(zhí)行邏輯必須等上一個(gè)執(zhí)行邏輯結(jié)束之后才執(zhí)行，并行就是兩個(gè)執(zhí)行邏輯互不干擾，所以并行相對(duì)來(lái)說(shuō)就比較節(jié)省時(shí)間，當(dāng)然是建立在沒(méi)有結(jié)果參數(shù)依賴(lài)的前提下。

比如，理財(cái)?shù)某謧}(cāng)信息展示接口，我們既需要查詢(xún)用戶(hù)的賬戶(hù)信息，也需要查詢(xún)商品信息和banner位信息等等來(lái)渲染持倉(cāng)頁(yè)，如果是串行，基本上接口耗時(shí)就是累加的。如果是并行，接口耗時(shí)將大大降低。

如圖：

?

7.索引

加索引能大大提高數(shù)據(jù)查詢(xún)效率，這個(gè)在接口設(shè)計(jì)之出也會(huì)考慮到，這里不再多贅述，隨著需求的迭代，我們重點(diǎn)整理一下索引不生效的一些場(chǎng)景，希望對(duì)小伙伴們有所幫助。

具體不生效場(chǎng)景不再一一舉例，后面有時(shí)間的話(huà)，單獨(dú)整理一下。

?

8.避免大事務(wù)

所謂大事務(wù)問(wèn)題，就是運(yùn)行時(shí)間較長(zhǎng)的事務(wù)，由于事務(wù)一致不提交，會(huì)導(dǎo)致數(shù)據(jù)庫(kù)連接被占用，影響到別的請(qǐng)求訪問(wèn)數(shù)據(jù)庫(kù)，影響別的接口性能。

舉個(gè)例子：

@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; }

所以為避免大事務(wù)問(wèn)題，我們可以通過(guò)以下方案規(guī)避：

1，RPC調(diào)用不放到事務(wù)里面

2，查詢(xún)操作盡量放到事務(wù)之外

3，事務(wù)中避免處理太多數(shù)據(jù)

9.優(yōu)化程序結(jié)構(gòu)

程序結(jié)構(gòu)問(wèn)題一般出現(xiàn)在多次需求迭代后，代碼疊加形成。會(huì)造成一些重復(fù)查詢(xún)、多次創(chuàng)建對(duì)象等耗時(shí)問(wèn)題。在多人維護(hù)一個(gè)項(xiàng)目時(shí)比較多見(jiàn)。解決起來(lái)也比較簡(jiǎn)單，我們需要針對(duì)接口整體做重構(gòu)，評(píng)估每個(gè)代碼塊的作用和用途，調(diào)整執(zhí)行順序。

10.深分頁(yè)問(wèn)題

深分頁(yè)問(wèn)題比較常見(jiàn)，分頁(yè)我們一般最先想到的就是 limit ，為什么會(huì)慢，我們可以看下這個(gè)SQL：

select * from purchase_record where productCode = 'PA9044' and status=4 and id > 100000 limit 200

這樣優(yōu)化的好處是命中了主鍵索引，無(wú)論多少頁(yè)，性能都還不錯(cuò)，但是局限性是需要一個(gè)連續(xù)自增的字段

11.SQL優(yōu)化

sql優(yōu)化能大幅提高接口的查詢(xún)性能，由于本文重點(diǎn)講述接口優(yōu)化的方案，具體sql優(yōu)化不再一一列舉，小伙伴們可以結(jié)合索引、分頁(yè)、等關(guān)注點(diǎn)考慮優(yōu)化方案。

12.鎖粒度避免過(guò)粗

鎖一般是為了在高并發(fā)場(chǎng)景下保護(hù)共享資源采用的一種手段，但是如果鎖的粒度太粗，會(huì)很影響接口性能。

關(guān)于鎖粒度：就是你要鎖的范圍有多大，不管是synchronized還是redis分布式鎖，只需要在臨界資源處加鎖即可，不涉及共享資源的，不必要加鎖，就好比你要上衛(wèi)生間，只需要把衛(wèi)生間的門(mén)鎖上就可以，不需要把客廳的門(mén)也鎖上。

錯(cuò)誤的加鎖方式：

//非共享資源 private void notShare(){ } //共享資源 private void share(){ } private int right(){ notShare(); synchronized (this) { share(); } }

?

二、最后

接口性能問(wèn)題形成的原因思考

我相信很多接口的效率問(wèn)題不是一朝一夕形成的，在需求迭代的過(guò)程中，為了需求快速上線(xiàn)，采取直接累加代碼的方式去實(shí)現(xiàn)功能，這樣會(huì)造成以上這些接口性能問(wèn)題。

變換思路，更高一級(jí)思考問(wèn)題，站在接口設(shè)計(jì)者的角度去開(kāi)發(fā)需求，會(huì)避免很多這樣的問(wèn)題，也是降本增效的一種行之有效的方式。

以上，共勉！

審核編輯 黃宇