
本文旨在解决前端应用中处理大量网络请求时遇到的api超时、403错误等问题。通过分析常见的错误尝试,文章重点介绍了如何利用bluebird.map进行并发控制,以及如何手动实现分批处理和延迟执行请求,从而有效管理请求负载,避免api限流,确保应用稳定性和用户体验。
在现代Web应用开发中,我们经常需要向后端API发送大量网络请求,例如批量数据更新、文件上传等场景。然而,当请求数量达到一定规模(如数百甚至上千个)时,直接使用Promise.all等方式并行发送所有请求,往往会导致以下问题:
以下是一个典型的、可能导致问题的Promise.all实现示例:
const retry = async (requests: API.CarFailedRequest[]) => {
setIsLoading(true);
const res = await Promise.all(
requests.map(async request => {
try {
await service.retryFailedRequest(request);
return { status: true, request };
} catch (e) {
return { status: false, request };
}
})
);
setIsLoading(false);
return res;
};这段代码的问题在于,requests.map内部的async request => {...}函数会立即执行,从而创建并启动所有的Promise。Promise.all随后等待所有这些已启动的Promise完成,但此时所有的网络请求已经同时发出,导致上述问题。
在尝试解决上述问题时,开发者可能会采取一些看似合理但实际上未能达到预期效果的策略。理解这些尝试为何失败,对于构建正确的解决方案至关重要。
一种常见的尝试是引入像 Bluebird 这样的第三方库,它提供了更强大的并发控制能力。然而,如果使用不当,效果可能不佳。
// 错误的 Bluebird.map 使用方式
const retry = async (requests: API.CarFailedRequest[]) => {
setIsLoading(true);
const promises = requests.map(async request => {
try {
await service.retryFailedRequest(request);
return true;
} catch (e) {
return false;
}
});
await BlueBirdPromise.map(
promises, // 注意:这里传入的是一个已启动的Promise数组
async promise => {
try {
await promise;
} catch (err) {
console.log(err);
}
},
{ concurrency: 10 }
);
setIsLoading(false);
};这段代码的问题在于,requests.map 仍然在 BlueBirdPromise.map 调用之前就创建并启动了所有的 Promise。promises 数组中存储的是已经开始执行的网络请求。BlueBirdPromise.map 的 concurrency 选项虽然限制了同时处理 Promise 结果的数量,但它无法阻止这些 Promise 在被传入 map 之前就全部启动。因此,网络请求仍然是瞬间全部发出的。
另一种思路是手动将请求分成小块(chunks),并尝试在每个块之间添加延迟。
// 错误的 manual chunking 方式
const processPromisesWithDelay = async (promises: any[], delay: number, split: number) => {
const chunks = [];
for (let i = 0; i < promises.length; i += split) {
chunks.push(promises.slice(i, i + split));
}
for (const chunk of chunks) {
await Promise.all(chunk.map((promise: () => any) => promise())); // 问题在这里:promise() 意味着立即执行
await new Promise((resolve) => setTimeout(resolve, delay * 1000));
}
};
const retry = async (requests: API.CarFailedRequest[]) => {
setIsLoading(true);
const promises = requests.map(async request => {
await service.retryFailedRequest(request); // 再次:所有请求在这里就启动了
});
await processPromisesWithDelay(promises, 5, 5); // 传入的是已启动的Promise数组
setIsLoading(false);
};与 Bluebird.map 的误用类似,requests.map 在 processPromisesWithDelay 调用之前就启动了所有请求。即使 processPromisesWithDelay 试图分批处理并添加延迟,它操作的仍然是已经发出的网络请求。在浏览器网络面板中,你会看到所有请求几乎同时处于“pending”状态,只是它们的完成时间被分批等待了,而不是请求的启动时间被分批了。
解决上述问题的关键在于,并发控制应该作用于请求的启动时机,而不是 Promise 的解决时机。Bluebird.map 正是为此设计的,但需要正确使用它。
核心思想是:将原始数据(而不是已启动的 Promise)传递给 Bluebird.map,并在 map 的迭代器函数中按需启动每个网络请求。这样,concurrency 选项才能真正限制同时进行的请求数量。
import BlueBirdPromise from 'bluebird'; // 确保已安装 bluebird
const retry = async (requests: API.CarFailedRequest[]) => {
setIsLoading(true);
await BlueBirdPromise.map(
requests, // 直接传入原始的请求数据数组
async request => { // 在这里,当 Bluebird.map 允许时,才启动请求
try {
await service.retryFailedRequest(request);
// 可以根据需要返回状态或数据
return { status: true, request };
} catch (err) {
console.error("请求失败:", request, err);
// 返回失败状态,或者根据错误类型进行重试
return { status: false, request, error: err };
}
},
{ concurrency: 10 } // 同时只允许 10 个请求处于活跃状态
);
setIsLoading(false);
// 返回处理结果,Bluebird.map 默认会返回一个包含所有迭代器返回值的数组
// 例如:const results = await BlueBirdPromise.map(...)
// return results;
};代码解析:
这种方法确保了网络请求是分批、有控制地发出的,从而有效避免了API限流和超时问题。
如果不想引入 Bluebird 库,或者需要对分批和延迟有更精细的控制,可以手动实现一个分批处理函数。关键在于,我们需要传递的是返回 Promise 的函数,而不是已经启动的 Promise。
/**
* 按批次处理异步任务,并在批次之间添加延迟。
* @param taskFns 数组,每个元素是一个返回 Promise 的函数。
* @param chunkSize 每批处理的任务数量。
* @param delayMs 每批次之间的延迟时间(毫秒)。
* @returns 所有任务完成后的结果数组。
*/
const processTasksInChunksWithDelay = async <T>(
taskFns: (() => Promise<T>)[],
chunkSize: number,
delayMs: number
): Promise<T[]> => {
const results: T[] = [];
for (let i = 0; i < taskFns.length; i += chunkSize) {
const chunkFns = taskFns.slice(i, i + chunkSize);
// 在这里才调用函数,启动 Promise
const chunkPromises = chunkFns.map(fn => fn());
const chunkResults = await Promise.all(chunkPromises);
results.push(...chunkResults);
// 如果还有后续批次,则进行延迟
if (i + chunkSize < taskFns.length) {
await new Promise(resolve => setTimeout(resolve, delayMs));
}
}
return results;
};
const retryWithManualChunks = async (requests: API.CarFailedRequest[]) => {
setIsLoading(true);
// 将每个请求封装成一个返回 Promise 的函数
const requestTaskFns = requests.map(request => async () => {
try {
await service.retryFailedRequest(request);
return { status: true, request };
} catch (e) {
console.error("请求失败:", request, e);
return { status: false, request, error: e };
}
});
// 调用分批处理函数,每5个请求一批,每批之间延迟5秒
const allResults = await processTasksInChunksWithDelay(requestTaskFns, 5, 5000);
setIsLoading(false);
return allResults;
};代码解析:
这种手动实现方式提供了极大的灵活性,可以精确控制每批次的请求数量和批次间的延迟时间,适用于需要严格遵守API速率限制的场景。
处理大量网络请求是前端开发中的常见挑战。通过本文的探讨,我们了解到直接使用 Promise.all 可能会导致API超时和资源耗尽。关键在于控制请求的启动时机。无论是利用 Bluebird.map 的 concurrency 选项,还是手动实现分批处理和延迟,核心原则都是将大量请求分解为可管理的批次,并控制每个批次内的并发数以及批次间的间隔。通过采纳这些策略并结合最佳实践,开发者可以构建出更健壮、更高效、用户体验更好的应用。
以上就是优化大量网络请求:分批处理、并发控制与超时策略的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号