前言

在新零售行业中，前端控制并发请求是保障系统稳定性、提升用户体验和优化资源利用的关键策略。

本文将从业务影响、具体线上问题示例及解决方案角度展开分析。

一、控制并发请求的核心原因

1.1 避免服务器过载与雪崩

问题本质：浏览器对同一域名的并发请求数存在限制（通常为6-8个）。若前端不加以控制，瞬时高并发请求可能导致：

• 后端服务线程池耗尽，响应延迟飙升。
• 数据库连接占满，关键服务（如支付、库存）瘫痪。

案例：某生鲜电商促销活动期间，首页一次性加载50张商品图片（每张图片独立请求），超出浏览器并发限制，导致图片加载队列阻塞，支付按钮点击后延迟超10秒，支付失败率激增40%。

1.2 防止资源竞争与数据错乱

问题本质：多请求同时操作同一资源（如库存）时，若前端未控制请求顺序，可能引发数据不一致。

案例：用户快速点击“抢购”按钮10次，前端未做防抖和并发控制，触发10次下单请求。后端库存扣减因无分布式锁，超卖5件商品，平台损失数万元并引发客诉。

1.3 优化用户体验与资源效率

问题本质：无限制的并发请求会占用网络带宽和客户端资源，导致页面卡顿、操作无响应。

案例：某超市线上平台的地图选店功能需加载大量瓦片数据，未做按需加载，首屏加载时间超8秒，用户流失率增加35%。

二、典型线上问题示例

2.1 秒杀活动中的请求风暴

场景：万人参与秒杀，用户频繁点击“立即购买”按钮。

问题：

• 前端未限制按钮点击频率，每秒生成数百请求，超出浏览器并发上限，请求排队导致界面卡死。
• 后端库存服务因瞬时高并发出现超卖（如100件商品售出120件）。

解决方案：

• 按钮点击防抖（如500ms内仅生效一次）。
• 使用Promise队列控制请求并发（如最大并发数5）：

// 使用p-limit库控制并发
import pLimit from 'p-limit';
const limit = pLimit(5); // 最大并发数5
urls.forEach(url => limit(() => fetch(url)));

2.2 批量数据加载导致的页面崩溃

场景：后台管理系统批量导出10,000条订单数据。

问题：前端一次性发起100个数据分页请求，浏览器并发队列阻塞，页面白屏5分钟。服务器CPU飙升至100%，影响正常订单查询服务。

解决方案：

• 前端分批请求：每批处理50条，逐批加载：

/**
 * 批量获取URL资源，按指定批次大小并发执行。
 * 
 * 该函数将URL数组分成多个批次，每个批次并发发送请求，并等待当前批次全部完成后再处理下一批次。
 * 
 * @param {string[]} urls - 需要获取的URL地址数组
 * @param {number} [batchSize=5] - 每批次并发请求的数量，默认值为5
 * @returns {Promise<void>} 异步操作，无返回值
 */
async function batchFetch(urls, batchSize = 5) {
  // 按批次遍历URL数组
  for (let i = 0; i < urls.length; i += batchSize) {
    // 获取当前批次的URL子数组
    const batch = urls.slice(i, i + batchSize);
    
    // 并发执行当前批次的所有请求并等待完成
    await Promise.all(batch.map(url => fetch(url)));
  }
}

2.3 实时消息推送阻塞关键操作

场景：客服系统同时接收100条用户消息推送。

问题：WebSocket消息无频率控制，占用浏览器并发通道，导致支付接口请求被延迟处理1。

解决方案：

• 前端消息队列：非关键消息延迟处理，优先保障支付等核心请求。

三、新零售行业的最佳实践

3.1 分层并发控制策略

3.2 关键优化技术

• 请求合并：将多个商品详情请求合并为单次批量查询（如GET /api/products?ids=1,2,3）。
• 请求去重：使用缓存拦截重复请求（如axios拦截器+Map存储指纹）：

// axios请求去重示例
/**
 * axios请求拦截器 - 实现重复请求取消功能
 * 
 * 该拦截器通过创建请求唯一标识，检测并复用相同请求的Promise对象，
 * 避免在请求未完成时重复发起相同请求。
 * 
 * @param {Object} config - axios请求配置对象
 * @returns {Promise} - 当前请求对应的Promise对象
 */
const pendingRequests = new Map();
axios.interceptors.request.use(config => {
  // 生成请求唯一标识：URL + 序列化参数
  const key = `${config.url}-${JSON.stringify(config.params)}`;

  // 检测重复请求
  if (pendingRequests.has(key)) {
    // 返回已存在的请求Promise
    return pendingRequests.get(key);
  }

  // 发起新请求并缓存Promise
  const request = axios(config).finally(() => {
    // 请求完成（成功/失败）后清理缓存
    pendingRequests.delete(key);
  });
  
  pendingRequests.set(key, request);
  return request;
});

• 核心逻辑：

• 根据请求配置生成唯一key。
• 检查是否存在相同key的pending请求。
• 若存在则返回已创建的Promise对象。
• 若不存在则发起新请求并缓存Promise。
• 请求完成后自动清理缓存。

• 按需加载：非首屏资源（如图片、地图瓦片）使用懒加载（Intersection Observer）。

3.3 监控与动态调整

• 指标监控：实时监测浏览器并发请求数（Chrome DevTools）、API响应时间。
• 动态阈值：根据网络环境（4G/Wi-Fi）调整最大并发数（弱网环境降至3-4）。

结语

在新零售场景下，前端控制并发请求不仅是技术优化，更是业务稳定的生命线：

• 防崩溃：避免浏览器阻塞与服务雪崩，保障核心流程（支付、库存）可用性。
• 降损失：通过原子操作与队列控制，杜绝超卖导致的资损风险。
• 提体验：分批加载、按需渲染使页面响应速度提升。

技术建议：

• 秒杀场景：前端防抖+队列，后端Redis Lua原子操作。
• 批量操作：分批次请求+服务端流式处理。
• 实时系统：消息分级+通道隔离。