這個問題(和最好的)的確切答案來自API文檔本身。我們使用它幾個月,它完美地解決了我的問題。
在這種情況下,最好的辦法是利用JS處理異步代碼的可能性,或者自己編寫簡單的退避或者使用其中一個很好的庫來使用。因此,如果偶然發現任何API限制(例如配額,5xx等),則應該使用退避來遞歸地再次運行查詢,但隨着延遲的增加(更多關於退避的信息可以在這裏找到:https://en.wikipedia.org/wiki/Exponential_backoff)。而且,如果最終在給定的次數之後再次失敗 - 優雅地返回關於API不可用的錯誤。
實施例下面使用(從https://www.npmjs.com/package/backoff截取):
var call = backoff.call(get, 'https://someaddress', function(err, res) {
console.log('Num retries: ' + call.getNumRetries());
if (err) {
// Put your error handling code here.
// Called ONLY IF backoff fails to help
console.log('Error: ' + err.message);
} else {
// Put your success code here
console.log('Status: ' + res.statusCode);
}
});
/*
* When to retry. Here - 503 error code returned from the API
*/
call.retryIf(function(err) { return err.status == 503; });
/*
* This lib offers two strategies - Exponential and Fibonacci.
* I'd suggest using the first one in most of the cases
*/
call.setStrategy(new backoff.ExponentialStrategy());
/*
* Info how many times backoff should try to post request
* before failing permanently
*/
call.failAfter(10);
// Triggers backoff to execute given function
call.start();
存在用於的NodeJS許多退避庫,利用的是第二上述任一無極式,回調式或甚至事件式的退避處理(例如提到的那些)。如果您瞭解回退算法本身,它們非常易於使用。由於退避參數可以存儲在配置中,如果退避失敗太頻繁,可以對其進行調整以獲得更好的結果。
如果是我,我不會做任何排隊的請求,而是告訴客戶端請求無法處理。 –
它純粹是後端功能,因此每個請求都必須作爲更大進程的一部分來完成 - 由於配額限制,它只能被延遲。 – SzybkiSasza
429太多請求[RFC6585](https://tools.ietf.org/html/rfc6585) – Fozi