Axios請求並發限制

Axios請求並發限制 - 簡書 https://www.jianshu.com/p/d3529d18cf59 

0.2352020.07.29 18:41:34字數 845閱讀 6,213

標簽

NodeJS並發請求，並行請求，QPS限制，Axios並發限制，Axios並發請求

背景

由於調用第三方服務的API的時候，第三方對請求的QPS會有一定的限制，如百度的人臉識別接口，QPS=5，騰訊地圖開放平台的普通賬號QPS=5，那么在使用的過程中如果每秒請求數超過此限制，接口就會返回報錯。導致請求失敗。因此，需要在本地實現QPS的控制，當把多個Axios的請求扔到Promise隊列中的時候，不會導致請求超限的問題。

眾所周知，Promise對象的運行並不是等調用Promise.all()的時候才會執行，而是在創建這個Promise的時候就已經開始執行了，所以從Promise這塊去下手顯然是無法實現的，需要在扔進Promise[]數組的這些Promise中去實現限制。

更多關於Promise並發等問題請自行學習了解，今天以Axios為例進行展開討論。

開始

對於一個Axios請求來說返回一個Promise，這個大家都知道的哈~ 正常的Axios請求大概寫成這樣：

const AXIOS = require('axios') async function AA() { let res = await AXIOS({ method: 'GET', url: 'https://www.baidu.com' }).then(res => res.data) console.log(res) } 

如果需要100個並發請求，則可以利用Promise.all()來實現：

const AXIOS = require('axios') async function BB() { // 定義一個Promise數組 let pms = [] for (let i = 0; i < 100; i++) { // 往pms中扔進去AXIOS返回的Promise對象們 pms.push(AXIOS({ method: 'GET', url: 'https://www.baidu.com' }).then(res => res.data).catch(err => console.error(err))) } // 通過Promise.all等待pms中所有的Promise執行完畢並返回結果給pms數組 pms = await Promise.all(pms) console.log(pms) } 

首先，如上面所說，這個請求的Promise是在創建的時候就已經開始執行了（甚至還沒push到pms[]中的時候它就已經在執行請求了）。所以如果百度這邊的QPS限制為5，同一秒的前5個請求可能可以成功，但是后面的請求就都會因為並發數超限導致失敗。當然，這里最簡單的方法就是通過for循環進行限制，讓for循環扔進去5個后就睡一會兒，睡到下一秒再繼續扔5個就好了。比如像下面這樣：

async function CC(QPS = 5) { const s = new Date().getTime() // 定義一個Promise數組 let pms = [] for (let i = 1; i <= 20; i++) { // 往pms中扔進去AXIOS返回的Promise對象們 pms.push(AXIOS({ method: 'GET', url: 'https://www.baidu.com' }).then(res => res.data).catch(err => console.error(err))) // 如果遇到QPS的倍數就歇1秒 if (i % QPS == 0) await new Promise(r => setTimeout(() => { r() }, 1000)) } // 通過Promise.all等待pms中所有的Promise執行完畢並返回結果給pms數組 pms = await Promise.all(pms) console.log(pms) console.log('運行耗時：', new Date().getTime() - s) } 

上述方式是可以實現的，但是也有一定的弊端，比如可能涉及到修改的地方比較多，而且像是foreach這種迭代可能還不支持for循環中的sleep，那么今天我們就以Axios的特性來實現。

Axios的並發請求控制

在了解了Axios文檔后得知，Axios有一個interceptors的攔截器機制，可以在發送請求前和請求結束返回前進行攔截，通過自定義函數實現消息的處理：【傳送門】

那么我們是不是可以通過這個攔截器中實現sleep的方式去進行QPS控制呢？說干咱就干！

首先自定義一個interceptors函數：

let qpsMap = new Map() const qpsController = (QPS = 5, OFFSET = 50) => async (config) => { const now = new Date().getTime() let { count, ts } = qpsMap.get(config.url) || { count: 1, ts: now } // console.log('Before', config.url, now, ts, count) // 對於Math.floor和parseInt來說，據說Math.floor性能更快 if (Math.floor(now / 1000) <= Math.floor(ts / 1000)) { // 如果當前時間 ≤ Map中該接口的ts時間，說明前面已經有超過並發后在等待的請求了 // 只比較秒，忽略毫秒，因為QPS是以秒為周期計算的，即每秒多少個請求數 if (count < QPS) { // 如果當前url的請求數沒有達到QPS的限制，則計數器+1 count++ } else { // 否則，重置計數器，同時將時間戳設置為當前ts的下一整秒 // 這里需要將ts設置為當前ts的下一秒，而不是當前時間，因為當前ts可能已經遠大於當前時間了 ts = 1000 * (Math.floor(ts / 1000) + 1) count = 1 } } else { // 否則：當前時間大於ts，說明已經沒有排隊的請求了（可能有未完成的，但是都已經請求了） // 則將當前ts重置 ts = now count = 1 } qpsMap.set(config.url, { count, ts }) // console.log('After ', config.url, now, ts, count) // 計算休眠時間： // 由於本地服務器和遠程服務器之間可能存在時間差會發生這種情況： // 前5個請求在10:00:00.200時發送過去后，此時本地時間可能到了10:00:00.900到來的第六請求由於超出了QPS=5的限制，會休眠100ms // 但是由於本地和服務端時間差的問題，第六個休眠100ms后發送了請求，服務端的時間可能才是10:00:00.950，導致了QPS超限報錯 // 所以，這里添加一個OFFSET偏移值來糾正本地和服務端之間的時間差問題，默認為50ms，若出現QPS超限，請酌情增大此值 let sleep = ts - now sleep = sleep > 0 ? sleep + OFFSET : 0 // console.log('Sleep Is', sleep) // 讓當前的請求睡一會兒再請求 await new Promise(resolve => setTimeout(() => resolve(), sleep)) // 原封不動返回config，或做一些你自己的處理后返回 return config } 

然后需要自定義一個AXIOS實例，並設置其request的interceptors為此函數：

async function BaiduClient(url = '', params = {}) { // 創建一個instance實例 let instance = AXIOS.create({ baseURL: 'http://www.baidu.com', timeout: 2000 }) // 配置本實例的interceptors為剛才的qpsController instance.interceptors.request.use(qpsController()) return await instance.request({ url, params }).then(response => response.status) } // 測試並發請求，並嘗試優化qpsController(QPS,OFFSET)中的參數值 let pms = [] for(let i=0;i<=10;i++){ pms.push(BaiduClient().then(res=>console.log(i, res))) } Promise.all(pms) 

20200812版本更新

經過一段時間的學習，我們知道獲取時間的時候通過Performance庫效率更高，而且通過位運算進行取整比通過Math庫效率高，同時將下一秒的計算由之前的下取整Math.floor改為了上取整Math.ceil，從而解決掉OFFSET問題。所以我們對qpsController函數進行如下改進：

// 引入Performance庫來獲取當前時間戳 const Performance = require('perf_hooks').performance let qpsMap = new Map() const qpsController = (QPS = 5, OFFSET = 0) => async (config) => { const now = Math.trunc(Performance.timeOrigin + Performance.now()) // Math.trunc(1597224439841.351)=1597224439841 let { count, ts } = qpsMap.get(config.url) || { count: 1, ts: now } // console.log('Before', config.url, now, ts, (now / 1000) >> 0 <= (ts / 1000) >> 0, count) // 通過位運算實現取整，提高效率 if ((now / 1000) >> 0 <= (ts / 1000) >> 0) { // 如果當前時間 ≤ Map中該接口的ts時間，說明前面已經有超過並發后在等待的請求了 // 只比較秒，忽略毫秒，因為QPS是以秒為周期計算的，即每秒多少個請求數 if (count < QPS) { // 如果當前url的請求數沒有達到QPS的限制，則計數器+1 count++ } else { // 否則，重置計數器，同時將時間戳設置為當前ts的下一整秒 // 這里需要將ts設置為當前ts的下一秒，而不是當前時間，因為當前ts可能已經遠大於當前時間了 // 這里修改以前的下取整為上取整，從而可以解決OFFSET問題 ts = 1000 * Math.ceil(ts / 1000 + 1) count = 1 } } else { // 否則：當前時間大於ts，說明已經沒有排隊的請求了（可能有未完成的，但是都已經請求了） // 則將當前ts重置 ts = now count = 1 } qpsMap.set(config.url, { count, ts }) // console.log('After ', config.url, now, ts, count) // 計算休眠時間： // 由於本地服務器和遠程服務器之間可能存在時間差會發生這種情況： // 前5個請求在10:00:00.200時發送過去后，此時本地時間可能到了10:00:00.900到來的第六請求由於超出了QPS=5的限制，會休眠100ms // 但是由於本地和服務端時間差的問題，第六個休眠100ms后發送了請求，服務端的時間可能才是10:00:00.950，導致了QPS超限報錯 // 所以，這里添加一個OFFSET偏移值來糾正本地和服務端之間的時間差問題，默認為0ms，若出現QPS超限，請酌情增大此值 let sleep = ts - now sleep = sleep > 0 ? sleep + OFFSET : 0 // console.log('Sleep Is', sleep) // 讓當前的請求睡一會兒再請求 await new Promise(resolve => setTimeout(() => resolve(), sleep)) // 原封不動返回config，或做一些你自己的處理后返回 return config