本篇內(nèi)容主要講解“前端的批量接口如何快速響應(yīng)”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“前端的批量接口如何快速響應(yīng)”吧!

為乳山等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及乳山網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站建設(shè)、乳山網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

昨天我們討論了服務(wù)間是否應(yīng)該提供批量接口的問(wèn)題，很多同學(xué)留言討論，非常好，一起討論一起進(jìn)步。

其中，留言最多的一種觀點(diǎn)是說(shuō)可以提供，但是要限制條數(shù)，比如每次最多傳1000條數(shù)據(jù)過(guò)來(lái)。

說(shuō)句實(shí)話，我們的項(xiàng)目很多也是這么做的。

不過(guò)我還是堅(jiān)持我的觀點(diǎn)，最好就不要提供批量接口。

因?yàn)殡S著數(shù)據(jù)量的不斷增大，勢(shì)必導(dǎo)致存儲(chǔ)架構(gòu)升級(jí)。

我們以商品查詢?yōu)槔?，?shù)據(jù)量變大，肯定是要上redis的吧，以前批量接口可能直接一個(gè)數(shù)據(jù)庫(kù)in就解決了，現(xiàn)在你是先走緩存還是不走呢?走的話要改代碼，不走的話性能肯定不高。數(shù)據(jù)量再繼續(xù)增大，分庫(kù)分表了，批量接口怎么處理?上Elasticsearch了，怎么處理?

這里，我們舉例是說(shuō)的批量查詢，如果換成批量操作呢?每次存儲(chǔ)架構(gòu)升級(jí)可能都要改這塊的代碼，而且還有另外一個(gè)操蛋的問(wèn)題，比如你們規(guī)定服務(wù)間調(diào)用超時(shí)最大是1秒鐘，超過(guò)1秒就有熔斷邏輯，那么，你要不要單獨(dú)為這個(gè)批量接口配置超時(shí)?

所以，批量接口極其容易形成瓶頸，需要花費(fèi)巨大的代價(jià)去維護(hù)這個(gè)代碼，還是不提供比較好。

當(dāng)然，如果你們的數(shù)據(jù)量在可以預(yù)見的未來(lái)都不會(huì)增長(zhǎng)到那么大，提供一個(gè)批量接口也不是不可以，視情況自行決定哈。(數(shù)據(jù)量都沒有，還不趕緊跑路?)

好了，關(guān)于昨天的問(wèn)題先嘮這么多，今天，我們看另外一個(gè)問(wèn)題：對(duì)前端提供的批量接口，后端如何快速響應(yīng)?有沒有通用的解決方案呢?

首先，我們分析一下這個(gè)場(chǎng)景。

這里說(shuō)的批量接口，肯定不是查詢哈，而是批量操作類的接口，比如批量導(dǎo)入，批量發(fā)貨，批量刪除，批量流轉(zhuǎn)，批量修改某種狀態(tài)，等等，有很多，不過(guò)做2C系統(tǒng)的可能比較少見，一般2B的系統(tǒng)會(huì)有非常多這種批量的接口，往往他們也是系統(tǒng)中的頑固，需要投入很多精力不斷打磨不斷優(yōu)化。

好了，場(chǎng)景我們清楚了，那么，怎么解決這類難題呢?

一般地，我們提供一個(gè)批量接口，前端傳一堆id過(guò)來(lái)，或者數(shù)據(jù)過(guò)來(lái)，后端慢慢處理，處理完了再給前端返回，因?yàn)槭?B的系統(tǒng)，用戶也愿意等待。

但是，這里其實(shí)有很多問(wèn)題，最典型的就是超時(shí)問(wèn)題，超時(shí)這個(gè)問(wèn)題說(shuō)簡(jiǎn)單也簡(jiǎn)單，說(shuō)復(fù)雜也復(fù)雜，以我們的系統(tǒng)為例，我們部署到華為云上面，可能會(huì)有這么幾個(gè)超時(shí)的地方：

• 1、華為云的防火墻有超時(shí);

• 2、華為云ELB有超時(shí);

• 3、前端nginx有超時(shí);

• 4、前端代碼里寫死了超時(shí);

• 5、后端網(wǎng)關(guān)有超時(shí);

• 6、后端服務(wù)有超時(shí);

• 7、遠(yuǎn)程調(diào)用有超時(shí);

所以，你看，一個(gè)超時(shí)問(wèn)題能把你折磨死，而且，這種問(wèn)題非常難排查，當(dāng)然，你躺完一次這個(gè)坑之后后面可能會(huì)好很多。(所以，我為什么知道這么多地方可能有問(wèn)題呢?)

超時(shí)只是一個(gè)典型的問(wèn)題，并不是全部，再說(shuō)一個(gè)情形，以批量發(fā)貨為例，晚上，很多商家都喜歡批量發(fā)貨，比如一次1000條，這么多商家的請(qǐng)求呢，一不小心就會(huì)出現(xiàn)很多打到同一臺(tái)機(jī)器上面去了，然后大家都在搞批量，都要申請(qǐng)大量的內(nèi)存，都在搞內(nèi)存，內(nèi)存扛不住呀，然后就OOM了，這是典型的請(qǐng)求傾斜的問(wèn)題，所以，怎么設(shè)置你的負(fù)載均衡策略呢?目前，并沒有很好的解決方案。

基于以上這些可能會(huì)出現(xiàn)的問(wèn)題，我一直在思考，能不能提供一種通用解決方案呢?

其實(shí)是有的，但是，要改原型。

比如，批量發(fā)貨，本來(lái)狀態(tài)只有未發(fā)貨、已發(fā)貨、發(fā)貨失敗，能不能加一個(gè)“發(fā)貨中”呢?

別小看這個(gè)發(fā)貨中的威力，真的很強(qiáng)大。

后端接收到批量發(fā)貨這個(gè)請(qǐng)求，先檢查數(shù)據(jù)的正確性，然后把數(shù)據(jù)庫(kù)這些單據(jù)的狀態(tài)改成發(fā)貨中，接著把這些數(shù)據(jù)一個(gè)一個(gè)的丟到消息隊(duì)列中，就可以返回了，前端查詢的時(shí)候就顯示發(fā)貨中，旁邊放一個(gè)刷新按鈕。此時(shí)，用戶完全去干別的事，比如去建商品，等會(huì)回來(lái)再看有沒有發(fā)貨完成或者發(fā)貨失敗的。

最后，有一組消費(fèi)者不斷的從消息隊(duì)列中消費(fèi)數(shù)據(jù)，調(diào)用物流服務(wù)發(fā)貨等等。

經(jīng)過(guò)這么一折騰，本來(lái)前端要hang死幾分鐘的請(qǐng)求幾秒鐘就返回了，用戶體驗(yàn)上去了，也不用去搞超時(shí)、請(qǐng)求傾斜等問(wèn)題了，解放了生產(chǎn)力，可以多劃水了。

而且，這還是一個(gè)可以無(wú)限橫向擴(kuò)展的架構(gòu)，隨著用戶量的不斷增大，理論上來(lái)說(shuō)，只要堆機(jī)器就可以了。

到此，相信大家對(duì)“前端的批量接口如何快速響應(yīng)”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！