如何優(yōu)化批量處理接口

本篇內(nèi)容主要講解“如何優(yōu)化批量處理接口”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“如何優(yōu)化批量處理接口”吧!

背景

同批量導(dǎo)入一樣，在我們的系統(tǒng)中，存在著大量的批量處理的接口，比如批量獲取運單，批量出庫，批量打印，等等，像這樣的接口大概有10幾個。

這些請求往往具有以下幾個特點：

1. 單條數(shù)據(jù)處理耗時較長，一般來說都在200ms及以上

2. 數(shù)據(jù)批量較大，像我們系統(tǒng)最大一頁是1000條數(shù)據(jù)，用戶可選擇的最大批量也就是1000

3. 總體耗時較長，比如按200ms和1000條數(shù)據(jù)算，總共就需要耗時200s，這個時間太長了

4. 這些單條的數(shù)據(jù)無法合并在一起進行處理

所以，我們有必要對批量處理的接口進行統(tǒng)一的性能優(yōu)化。

但是，要如何進行優(yōu)化呢？

如何優(yōu)化

我們知道單臺機器的性能是有上限的，像這種批量請求，一方面會占用大量的內(nèi)存，同時也會占用很高的CPU，全部放在同一個進程里面處理勢必導(dǎo)致整體處理時間更進一步上升，所以，針對這種批量的請求，最好的辦法就是分而治之。

什么是分而治之呢？

分而治之，在很多場景中都有用到，比如上一篇我們說的批量導(dǎo)入，它一般分成四個部分：

1. 接收請求

2. 分發(fā)請求

3. 處理請求

4. 匯總請求

那么，在我們這個批量處理的過程中如何應(yīng)用分而治之的思想呢？

首先，我們要把大批量請求改成一個一個的小請求，這里的“改”是指我們后端來改，而不是前端調(diào)用來修改，前端還是調(diào)用大批量的請求。

然后，通過某種機制把這些小請求分發(fā)到多臺機器上進行處理，比如，使用Kafka來做分發(fā)器。

最后，再統(tǒng)計每個小請求的完成情況，當(dāng)所有的小請求都完成了之后，就通知前端整個請求已完成。

這里的通知可以走消息模塊，同時，上面的完成小請求的改造后就可以返回前端了，等到這里全部完成再異步通知。

好了，我們直接來看我的架構(gòu)設(shè)計圖：

整體來說，還是蠻復(fù)雜的，讓我們每個步驟來過一遍：

1. 接收請求，前端請求后端的大批量接口

2. 記錄本次批量處理請求的信息，比如分配請求號、哪個用戶、哪個操作、總共多少條、成功0條、失敗0條，等等

3. 批量更新數(shù)據(jù)庫中這些數(shù)據(jù)的狀態(tài)為xxx處理中，并記錄原來的狀態(tài)，這里使用mysql的批量更新，速度很快

4. 把大批量的數(shù)據(jù)一條一條的發(fā)到Kafka中，Kafka承擔(dān)了分發(fā)器的作用

5. 給前端返回響應(yīng)，說明本次請求收到了，并且在處理中了，這樣界面上查詢的結(jié)果就是這些單據(jù)正在xxx處理中

6. 多個服務(wù)實例從Kafka拉取消息來消費

7. 針對每一條數(shù)據(jù)進行處理，比如檢查權(quán)限、參數(shù)，處理復(fù)雜的業(yè)務(wù)邏輯，等等，并寫入mysql處理的結(jié)果

8. 記錄每一條數(shù)據(jù)的處理結(jié)果到redis中，比如成功條數(shù)+1，失敗條數(shù)+1，等等

9. 當(dāng)檢測到所有數(shù)據(jù)都處理完了，即總共條數(shù)=成功條數(shù)+失敗條數(shù)，就發(fā)個消息到消息服務(wù)

10. 消息服務(wù)發(fā)送一個新的通知給前端：您剛才進行的XXX操作已完成，成功X條，失敗X條

11. 前端收到這個通知后，檢查如果還在這個界面，就自動刷新下頁面，等等，可以做一些很友好的交互

這就是整體批量請求的處理過程，怎么樣，還可以接受不？

另外，因為我們系統(tǒng)中的批量處理接口實在是太多了，如果每個接口都這樣實現(xiàn)一遍，有很多重復(fù)的代碼。

所以，我們可以做一個通用的批量接口，通過配置元數(shù)據(jù)的形式實現(xiàn)，元數(shù)據(jù)的格式為：{action: xx操作，targetStatus: xx處理中}，這樣除了中間的處理消息的過程無法復(fù)用外，其他的部分都是可以復(fù)用的。

好了，接著我們再來回顧下這種騷操作可以運用到哪些場景呢？

運用場景

1. 單條數(shù)據(jù)處理耗時較長，如果單條數(shù)據(jù)處理耗時非常短則沒必要

2. 數(shù)據(jù)批量較大，如果一次批量不大則沒必要

3. 總體耗時較長，上面兩個因素的疊加，如果總體耗時不長則沒必要

4. 無法進行批量更新數(shù)據(jù)庫的場景，如果可以批量更新數(shù)據(jù)庫則沒必要

最后，我們再看看還有哪些改進措施呢？

改進措施

我認為主要有以下兩種改進措施：

1. 不一定每次請求都是大批量，比如說，如果一次請求的數(shù)據(jù)量小于10條，是不是本機直接處理更快呢？

2. 不是每個批量場景都需要優(yōu)化，見上面運用場景分析的沒必要場景

到此，相信大家對“如何優(yōu)化批量處理接口”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！