请求防抖：多场景解决方案

今天在维护博客系统时，遇到了一个并发导致的多次请求问题，由于这个问题是非常常见的，所以在这里记录下各种解决方案。

博客的AI摘要是lazy load的，当请求某篇文章但是发现并没有摘要和关键词，才会向星火大模型发送异步请求，填写数据库中这两个字段。大模型的请求一般耗时10s左右，如果在这10s不断刷新文章页面，就会导致不断去发送异步请求。其实这就是典型的接口重复请求问题，在不同场景中有不同的表现形式，比如电商中的重复下单。

解决防抖/重复请求的方案的本质就是用一个标志来记录已经发送过请求了，后续遇到这个标志就不请求。不同场景中，无非将这个标志放到内存、数据库、redis、消息队列中。

1. 内存锁方案

const processingMap = new Map<string, boolean>();



async function process(id: string) {

  if (processingMap.get(id)) {

    return;

  }

  processingMap.set(id, true);

  try {

    // 处理逻辑

  } finally {

    processingMap.delete(id);

  }

}

| 适用场景 | 优点 | 缺点 |

| --------------------------- | ------------ | ------------------ |

| 单体服务 | 实现简单 | 服务重启后状态丢失 |

| 短时间并发处理 | 性能最好 | 不支持分布式 |

| 内存占用敏感， 对性能要求高 | 内存占用最小 | 无法获取处理结果 |

2. Promise 缓存方案

const processingCache = new Map<string, Promise<any>>();



async function process(id: string) {

  if (processingCache.has(id)) {

    return processingCache.get(id);

  }

  

  const promise = (async () => {

    try {

      // 处理逻辑

      return result;

    } finally {

      processingCache.delete(id);

    }

  })();

  

  processingCache.set(id, promise);

  return promise;

}

| 适用场景 | 优点 | 缺点 |

| -------------------- | ---------------- | ------------ |

| 单体服务 | 可以返回处理结果 | 实现相对复杂 |

| 需要返回处理结果 | 错误处理完善 | 内存占用较大 |

| 需要错误处理 | 代码可维护性好 | 不支持分布式 |

| 并发请求需要等待结果 | | |

3. 数据库锁方案

async function process(id: string) {

  const record = await prisma.task.findUnique({

    where: { id }

  });

  

  if (record?.isProcessing) {

    return;

  }

  

  await prisma.task.update({

    where: { id },

    data: { isProcessing: true }

  });

  

  try {

    // 处理逻辑

  } finally {

    await prisma.task.update({

      where: { id },

      data: { isProcessing: false }

    });

  }

}

| 适用场景 | 优点 | 缺点 |

| ------------------ | ------------ | -------------------- |

| 分布式服务 | 支持分布式 | 性能较差 |

| 需要持久化处理状态 | 状态持久化 | 实现复杂 |

| 对数据一致性要求高 | 数据一致性好 | 需要额外的数据库操作 |

| 可以接受性能损耗 | | |

4. Redis 分布式锁

async function process(id: string) {

  const lockKey = `lock:${id}`;

  const acquired = await redis.set(lockKey, '1', 'EX', 60, 'NX');

  

  if (!acquired) {

    return;

  }

  

  try {

    // 处理逻辑

  } finally {

    await redis.del(lockKey);

  }

}

| 适用场景 | 优点 | 缺点 |

| -------------- | ------------ | -------------- |

| 分布式服务 | 性能好 | 需要维护 Redis |

| 高性能要求 | 支持分布式 | 实现复杂 |

| 需要超时机制 | 自带超时机制 | 成本较高 |

| 对可靠性要求高 | 可靠性高 | |

5. 消息队列方案

import PQueue from 'p-queue';



const queue = new PQueue({ concurrency: 1 });



async function process(id: string) {

  queue.add(async () => {

    // 处理逻辑

  });

}

| 适用场景 | 优点 | 缺点 |

| ---------------- | ---------- | ---------------- |

| 需要控制并发数 | 可控制并发 | 服务重启丢失队列 |

| 任务可以排队处理 | 支持优先级 | 内存占用大 |

| 需要任务优先级 | 实现简单 | 不支持分布式 |

| 内存占用不敏感 | | |

选择建议

| 场景 | 选择方案 | 原因 |

| ------------------------ | ---------------- | ------------------------------ |

| 单体服务，简单场景 | 内存锁方案 | 简单高效，满足基本需求 |

| 单体服务，需要结果返回 | Promise 缓存方案 | 可以处理异步结果，错误处理完善 |

| 分布式服务，高性能要求 | Redis 分布式锁 | 性能好，支持分布式，可靠性高 |

| 分布式服务，强一致性要求 | 数据库锁方案 | 数据一致性好，状态可持久化 |

| 需要控制并发数量 | 消息队列方案 | 可以精确控制并发，支持任务排队 |

最后，在实际应用中，这些方案也可以组合使用，比如：

• Redis 锁 + 消息队列

• 数据库锁 + Promise 缓存

• 内存锁 + 防抖处理