API请求ID重复校验：1小时时效控制方案可行性问询

一、关于“每小时重置的请求ID状态模型”的可行性 #

不建议单独做“每小时重置”的本地计时器模型，核心原因如下：

• 多实例部署场景下，每个实例的本地计时器独立运行，会导致不同实例对同一请求ID的判断不一致，破坏业务逻辑一致性。
• 服务重启后，本地计时器状态会丢失，导致之前的请求记录判断失效。
• 依赖数据库存储的时间戳进行判断，比本地计时器更可靠、更易维护。

二、MongoDB文档设计修正 #

要解决之前仅存日期导致的永久重复错误问题，必须存储带精确时分秒的时间戳，而非仅日期。推荐的文档结构如下：

{
  "_id": ObjectId("664d2b8f1a2b3c4d5e6f7a8b"),
  "requestId": "1", // 添加唯一索引，确保同一ID仅存一条有效记录
  "receivedAt": ISODate("2024-05-20T10:00:00Z"), // 精确到秒的请求接收时间
  "responseData": { // 保存的响应内容，可根据业务调整结构
    "statusCode": 200,
    "body": "{\"result\":\"success\"}"
  }
}

关键优化点：

• 给requestId字段加唯一索引，避免同一ID在1小时内被重复插入。
• receivedAt使用MongoDB原生ISODate类型，自带精确时间戳，便于后续计算时间差。

三、具体处理流程实现 #

按照你更新后的流程，代码逻辑可参考如下示例（以Node.js为例）：

async function handleRequest(req) {
  const requestId = req.params.id;
  const requestRecords = db.collection('requestRecords');
  
  // 1. 查询该ID的历史记录
  const existingRecord = await requestRecords.findOne({ requestId });
  
  if (!existingRecord) {
    // 2. 无记录：执行正常业务流程
    const response = await processBusinessLogic(req);
    // 保存记录到MongoDB
    await requestRecords.insertOne({
      requestId,
      receivedAt: new Date(),
      responseData: response
    });
    return response;
  } else {
    // 3. 有记录：计算时间差
    const timeDiff = Date.now() - existingRecord.receivedAt.getTime();
    const oneHourMs = 60 * 60 * 1000; // 1小时对应的毫秒数
    
    if (timeDiff < oneHourMs) {
      // 3.1 不足1小时：返回保存的响应
      return existingRecord.responseData;
    } else {
      // 3.2 超过1小时：返回重复ID错误
      return { statusCode: 400, error: "idrequest already used" };
    }
  }
}

四、额外注意事项 #

• 分布式一致性：所有API实例共享同一MongoDB数据源，确保不同实例对同一请求ID的判断逻辑完全一致，避免多实例场景下的冲突。
• 记录保留策略：如果业务不需要永久保留请求记录，可以给receivedAt字段添加TTL索引，设置24小时或更久的过期时间，自动清理旧记录，减少存储压力。
• 异常场景优化：如果正常流程执行中出现崩溃等异常，可考虑添加“处理中”状态字段，避免重复执行未完成的流程，这属于进阶优化，可根据实际需求调整。

内容的提问来源于stack exchange，提问作者Marduk