《优化接口设计的思路》系列：第六篇—接口防抖(防重复提交)的一些方式

一、接口防抖的核心价值：为何必须重视重复提交问题？

在用户高频操作的场景中（如支付、表单提交），网络延迟、按钮连击或重试逻辑可能导致同一请求被多次发送。这种”重复提交”会引发三类严重后果：

1. 业务逻辑异常：例如支付接口重复调用可能导致用户被重复扣款
2. 数据一致性破坏：库存系统可能因重复下单出现超卖
3. 系统性能损耗：无意义的重复请求占用服务器资源

防抖技术的本质是通过时间窗口控制、请求标识等机制，确保同一操作在特定时间内仅被处理一次。其实现需兼顾用户体验（避免误拦截正常操作）和系统安全（严格限制恶意请求）。

二、前端防抖：第一道防护线的构建

1. 按钮级防抖实现

// 基于lodash的防抖函数
import { debounce } from 'lodash';
const submitButton = document.getElementById('submit');
submitButton.addEventListener('click', debounce(() => {
  // 实际提交逻辑
  fetch('/api/submit', { method: 'POST' })
    .then(response => console.log('提交成功'));
}, 1000)); // 1秒内仅允许一次点击

适用场景：表单提交、搜索框输入等用户主动触发操作
优势：实现简单，无需改造后端
局限：无法防御通过代码直接发起的重复请求

2. 请求锁机制

let isSubmitting = false;
async function handleSubmit() {
  if (isSubmitting) return;
  isSubmitting = true;
  try {
    await fetch('/api/submit', { method: 'POST' });
  } finally {
    isSubmitting = false;
  }
}

通过状态变量控制请求流程，适合SPA应用中需要精细控制提交状态的场景。

三、后端防抖：核心防护层的实现

1. 时间戳校验方案

实现逻辑：

1. 客户端在请求体中添加当前时间戳timestamp
2. 服务端验证时间差是否超过阈值（如5秒）

   // Spring Boot示例
   @PostMapping("/submit")
   public ResponseEntity<?> submit(@RequestBody RequestData data) {
    long current = System.currentTimeMillis();
    if (Math.abs(current - data.getTimestamp()) > 5000) {
        return ResponseEntity.badRequest().body("请求过期");
    }
    // 正常处理逻辑
   }

   优化点：需结合客户端时钟同步策略，防止用户修改本地时间绕过校验

2. Token防重复机制

完整流程：

1. 客户端首次请求时获取唯一Token
2. 提交时携带Token，服务端校验后立即失效该Token
3. 重复请求因Token无效被拦截

Redis实现示例：

// 生成Token
public String generateToken() {
    String token = UUID.randomUUID().toString();
    redisTemplate.opsForValue().set(token, "1", 5, TimeUnit.MINUTES);
    return token;
}
// 校验Token
public boolean validateToken(String token) {
    Boolean exists = redisTemplate.delete(token); // 原子操作
    return Boolean.TRUE.equals(exists);
}

关键设计：Token需设置合理过期时间，防止内存泄漏

四、混合防抖：前后端协同防护

1. 双重校验模式

sequenceDiagram
    客户端->>服务端: GET /token (获取防重Token)
    服务端-->>客户端: 返回Token
    客户端->>服务端: POST /submit (携带Token)
    服务端->>服务端: 校验Token有效性
    服务端-->>客户端: 成功响应后删除Token

优势：前端拦截大部分误操作，后端保障最终安全性

2. 幂等性设计

对于支付等关键接口，需实现真正的幂等：

// 数据库表设计示例
CREATE TABLE orders (
    id VARCHAR(32) PRIMARY KEY,
    order_no VARCHAR(32) UNIQUE,
    status TINYINT,
    create_time DATETIME
);
// 服务层实现
public Order createOrder(OrderRequest request) {
    // 1. 检查订单号是否已存在
    if (orderRepository.existsByOrderNo(request.getOrderNo())) {
        return orderRepository.findByOrderNo(request.getOrderNo());
    }
    // 2. 创建新订单
    Order order = new Order();
    order.setOrderNo(request.getOrderNo());
    // ...其他字段设置
    return orderRepository.save(order);
}

通过唯一约束保证重复请求不会创建重复数据。

五、进阶方案：分布式环境下的防抖

1. Redis分布式锁

// 使用Redisson实现
RLock lock = redissonClient.getLock("submit_lock:" + userId);
try {
    boolean isLocked = lock.tryLock(1, 5, TimeUnit.SECONDS);
    if (isLocked) {
        // 执行业务逻辑
    }
} finally {
    lock.unlock();
}

适用场景：需要严格串行化的关键操作

2. 消息队列去重

通过将请求转为消息，利用消息ID实现去重：

# RabbitMQ示例
def on_message(channel, method, properties, body):
    message_id = properties.message_id
    if redis.get(message_id):
        return  # 重复消息
    redis.setex(message_id, 3600, "1")
    # 处理业务逻辑

六、性能与安全的平衡艺术

1. 时间窗口选择：

   • 表单提交：500ms-2s
   • 支付操作：3-5s
   • 实时性要求高的接口：200-500ms

2. 异常处理机制：

   @Retryable(value = {DuplicateRequestException.class}, 
              maxAttempts = 3, 
              backoff = @Backoff(delay = 1000))
   public void processRequest(Request request) {
       // 业务逻辑
   }

3. 监控体系构建：

   • 记录重复请求率（正常应<0.5%）
   • 设置告警阈值（如重复率>1%时触发）
   • 定期分析重复请求模式

七、实践建议：分阶段实施策略

1. 基础防护阶段：

   • 前端按钮防抖（500ms）
   • 后端时间戳校验

2. 进阶防护阶段：

   • 引入Token机制
   • 关键接口幂等改造

3. 高可用阶段：

   • 分布式锁方案
   • 消息队列去重
   • 全链路监控

结语

接口防抖是保障系统稳定性的重要环节，其实现需要综合考虑业务场景、性能要求和安全等级。建议开发者从前端简单防抖入手，逐步构建包含Token校验、幂等设计和分布式锁的多层防护体系。在实际项目中，可通过A/B测试验证不同方案的拦截效果，最终形成适合自身业务的防重复提交解决方案。