引言

在分布式系统与高并发场景下，接口防抖与防重复提交已成为保障系统稳定性的关键技术。无论是用户误操作导致的重复点击，还是网络延迟引发的请求重试，都可能引发数据不一致、业务逻辑错误甚至系统崩溃。本文作为《优化接口设计的思路》系列第六篇，将从前端、后端、数据库及分布式架构四个层面，系统解析接口防抖的实现策略，为开发者提供可落地的技术方案。

一、前端防抖：按钮级与请求级双重控制

1.1 按钮级防抖：基于时间的请求拦截

前端防抖的核心是限制用户操作频率。以按钮点击为例，可通过设置定时器实现：

let timer = null;
document.getElementById('submitBtn').addEventListener('click', () => {
  if (timer) clearTimeout(timer);
  timer = setTimeout(() => {
    // 实际提交逻辑
    submitForm();
  }, 1000); // 1秒内仅允许一次提交
});

此方案适用于表单提交、搜索等场景，但需注意：

• 定时器清理：避免内存泄漏，需在组件卸载时清除定时器。
• 用户体验：可通过禁用按钮或显示加载状态提升交互友好性。

1.2 请求级防抖：Axios拦截器实践

对于复杂场景，可通过Axios拦截器统一处理重复请求：

const pendingRequests = new Map();
axios.interceptors.request.use(config => {
  const requestKey = `${config.method}-${config.url}`;
  if (pendingRequests.has(requestKey)) {
    return Promise.reject('重复请求中');
  }
  pendingRequests.set(requestKey, true);
  return config;
});
axios.interceptors.response.use(response => {
  const requestKey = `${response.config.method}-${response.config.url}`;
  pendingRequests.delete(requestKey);
  return response;
}, error => {
  const requestKey = `${error.config.method}-${error.config.url}`;
  pendingRequests.delete(requestKey);
  return Promise.reject(error);
});

此方案可全局拦截重复请求，但需注意：

• 请求标识：需根据业务场景扩展标识（如添加参数）。
• 错误处理：需区分网络错误与业务错误。

二、后端防重复：Token验证与幂等性设计

2.1 Token验证机制

后端防重复的核心是确保每次请求的唯一性。常见方案包括：

• 客户端生成Token：前端生成唯一Token（如UUID），随请求发送至后端，后端校验后销毁。
• 服务端生成Token：后端生成Token并返回前端，前端需携带Token请求。

实现示例（Spring Boot）：

@RestController
public class OrderController {
    private final RedisTemplate<String, String> redisTemplate;
    @GetMapping("/generateToken")
    public String generateToken() {
        String token = UUID.randomUUID().toString();
        redisTemplate.opsForValue().set(token, "1", 5, TimeUnit.MINUTES);
        return token;
    }
    @PostMapping("/submitOrder")
    public ResponseEntity<?> submitOrder(@RequestHeader("X-Token") String token) {
        Boolean exists = redisTemplate.hasKey(token);
        if (!exists) {
            return ResponseEntity.badRequest().body("重复提交");
        }
        redisTemplate.delete(token);
        // 业务逻辑
        return ResponseEntity.ok("提交成功");
    }
}

关键点：

• Token有效期：需根据业务场景设置（如5分钟）。
• 分布式支持：Redis需支持集群模式。

2.2 幂等性设计

对于不可逆操作（如支付），需通过幂等性设计确保重复请求不影响结果：

• 唯一索引：数据库层面添加唯一约束（如订单号）。
• 状态机：业务逻辑中记录操作状态（如“已支付”）。

数据库示例：

CREATE TABLE orders (
    order_id VARCHAR(32) PRIMARY KEY,
    status VARCHAR(10) NOT NULL DEFAULT 'PENDING',
    UNIQUE (order_id)
);

三、数据库层防护：唯一约束与事务控制

3.1 唯一约束的应用

数据库唯一约束是防重复的最后一道防线。例如，用户注册场景可通过手机号唯一约束防止重复注册：

CREATE TABLE users (
    user_id INT AUTO_INCREMENT PRIMARY KEY,
    phone VARCHAR(11) UNIQUE NOT NULL,
    username VARCHAR(50) NOT NULL
);

注意事项：

• 并发冲突：高并发下可能触发唯一约束异常，需结合事务处理。
• 错误处理：需捕获DuplicateKeyException并返回友好提示。

3.2 事务控制

对于复杂业务，需通过事务确保数据一致性：

@Transactional
public void createOrder(Order order) {
    // 1. 检查订单是否存在
    if (orderRepository.existsByOrderId(order.getOrderId())) {
        throw new RuntimeException("订单已存在");
    }
    // 2. 保存订单
    orderRepository.save(order);
    // 3. 更新库存（示例）
    inventoryService.reduceStock(order.getProductId(), order.getQuantity());
}

四、分布式锁：高并发场景下的终极方案

4.1 Redis分布式锁实现

在分布式系统中，Redis分布式锁可确保同一时间仅一个请求处理业务：

public class DistributedLock {
    private final RedisTemplate<String, String> redisTemplate;
    public boolean tryLock(String lockKey, String requestId, long expireTime) {
        Boolean success = redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, expireTime, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }
    public boolean releaseLock(String lockKey, String requestId) {
        String value = redisTemplate.opsForValue().get(lockKey);
        if (requestId.equals(value)) {
            return Boolean.TRUE.equals(redisTemplate.delete(lockKey));
        }
        return false;
    }
}

使用示例：

@RestController
public class PaymentController {
    private final DistributedLock distributedLock;
    @PostMapping("/pay")
    public ResponseEntity<?> pay(@RequestBody PaymentRequest request) {
        String lockKey = "payment:" + request.getOrderId();
        String requestId = UUID.randomUUID().toString();
        try {
            if (!distributedLock.tryLock(lockKey, requestId, 10)) {
                return ResponseEntity.badRequest().body("操作中，请勿重复提交");
            }
            // 业务逻辑
            paymentService.process(request);
            return ResponseEntity.ok("支付成功");
        } finally {
            distributedLock.releaseLock(lockKey, requestId);
        }
    }
}

关键点：

• 锁超时：需设置合理超时时间，避免死锁。
• 锁续期：长事务需支持锁续期（如Redisson）。

4.2 Redisson实现

Redisson提供了更完善的分布式锁实现：

@Bean
public RedissonClient redissonClient() {
    Config config = new Config();
    config.useSingleServer().setAddress("redis://127.0.0.1:6379");
    return Redisson.create(config);
}
@RestController
public class OrderController {
    private final RedissonClient redissonClient;
    @PostMapping("/createOrder")
    public ResponseEntity<?> createOrder(@RequestBody OrderRequest request) {
        RLock lock = redissonClient.getLock("order:" + request.getOrderId());
        try {
            boolean locked = lock.tryLock(5, 10, TimeUnit.SECONDS);
            if (!locked) {
                return ResponseEntity.badRequest().body("操作中，请勿重复提交");
            }
            // 业务逻辑
            orderService.create(request);
            return ResponseEntity.ok("订单创建成功");
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return ResponseEntity.status(500).body("系统错误");
        } finally {
            if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

五、综合方案：多层级防重复策略

实际项目中，需结合前端防抖、后端Token验证、数据库唯一约束及分布式锁构建多层级防护：

1. 前端防抖：拦截用户误操作。
2. 后端Token验证：防止恶意重复请求。
3. 数据库唯一约束：确保数据唯一性。
4. 分布式锁：高并发场景下的终极保障。

示例流程：

1. 用户点击提交按钮，前端启动1秒防抖。
2. 前端携带Token请求后端。
3. 后端校验Token有效性，若无效则返回409冲突。
4. 后端通过分布式锁获取资源，执行业务逻辑。
5. 数据库通过唯一约束确保数据不重复。

六、总结与建议

接口防抖与防重复提交是保障系统稳定性的关键技术。开发者需根据业务场景选择合适方案：

• 低并发场景：前端防抖 + 后端Token验证。
• 中并发场景：前端防抖 + 后端Token验证 + 数据库唯一约束。
• 高并发场景：前端防抖 + 后端Token验证 + 分布式锁 + 数据库唯一约束。

最佳实践建议：

1. 统一错误码：定义重复提交的错误码（如409 CONFLICT）。
2. 日志记录：记录重复请求的上下文信息，便于排查问题。
3. 监控告警：对重复请求率进行监控，及时发现异常。
4. 性能优化：分布式锁需考虑性能影响，避免成为瓶颈。

通过多层级防护与精细化设计，可显著提升接口的稳定性与用户体验，为业务发展提供坚实的技术保障。