一、背景

針對老專案，去年做了許多降本增效的事情，其中發現最多的就是介面耗時過長的問題，就集中搞了一次介面效能最佳化。本文將給小夥伴們分享一下介面最佳化的通用方案。

二、介面最佳化方案總結

1. 批處理

批次思想：批次運算元據庫，這個很好理解，我們在迴圈插入場景的介面中，可以在批處理執行完成後一次性插入或更新資料庫，避免多次 IO。

//for迴圈單筆入庫list.stream().forEatch(msg->{
    insert();});

//批次入庫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();
        //插入賬戶任務
        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 = "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 order by orderTime desc limit 100000,200

limit 100000,200 意味著會掃描 100200 行，然後返回 200 行，丟棄掉前 100000 行。所以執行速度很慢。一般可以採用標籤記錄法來最佳化，比如：

    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 wrong(){
            synchronized (this) {
                share();
                notShare();
            }
        }

正確的加鎖方式：

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

三、最後

介面效能問題形成的原因思考

我相信很多介面的效率問題不是一朝一夕形成的，在需求迭代的過程中，為了需求快速上線，採取直接累加程式碼的方式去實現功能，這樣會造成以上這些介面效能問題。

變換思路，更高一級思考問題，站在介面設計者的角度去開發需求，會避免很多這樣的問題，也是降本增效的一種行之有效的方式。

介面最佳化的常見方案實戰總結