前言
当你的用户疯狂点击提交按钮时，你的系统准备好迎接这场“连击风暴”了吗？
在电商系统的实战中，我见过太多因重复提交导致的资损事故——用户一次点击，系统却创建了多个订单，导致库存错乱、用户重复支付、客服投诉爆棚。
有些小伙伴在工作中可能遇到过这样的场景：大促期间，用户反馈“明明只点了一次，为什么扣了两次款？”
开发同学查了半天日志，发现同一个用户请求在毫秒级内真的到达了服务器两次。
今天这篇文章就跟大家聊聊高并发下防止重复提交订单，希望对你会有所帮助。
01 为什么会重复提交？
在深入解决方案前，我们必须搞清楚重复提交是如何发生的。
常见的场景有：
用户无意识重复点击：网络延迟时，用户心急多次点击提交按钮
前端防抖失效：前端做了防抖处理，但被绕过或配置不当
网络超时重试：请求超时后，客户端或网关自动重试
恶意攻击：竞争对手或黑客故意重复提交
后端处理超时：第一个请求处理慢，客户端以为失败又发一次
来看一个典型的用户操作流程，以及其中可能发生重复的各个环节：
从图中可以看到，从用户点击到订单落库，几乎每个环节都可能成为重复提交的“案发现场”。
下面，我们就针对这些环节，层层布防。
02 第一道防线：前端防抖与按钮控制
这是最直观、成本最低的防护措施。
原则是：在用户交互层面尽量减少无效请求。
2.1 按钮状态控制
// 前端防抖实现示例（Vue + Element UI） <template> <el-button :loading="submitting" :disabled="submitting" @click="handleSubmitOrder" > {{ submitting ? '提交中...' : '提交订单' }} </el-button> </template> <script> export default { data() { return { submitting: false, submitToken: null // 用于标识当前提交的token } }, methods: { async handleSubmitOrder() { if (this.submitting) { this.$message.warning('正在提交，请勿重复点击') return } this.submitting = true try { // 生成唯一token，用于后端幂等性校验 this.submitToken = this.generateSubmitToken() const result = await this.$api.order.submit({ orderData: this.orderData, submitToken: this.submitToken }) this.$message.success('订单提交成功') this.$router.push(`/order/detail/${result.orderId}`) } catch (error) { this.$message.error(`提交失败: ${error.message}`) this.submitting = false // 失败后重置状态 } }, generateSubmitToken() { // 生成唯一标识，可以用UUID或时间戳+随机数 return `order_submit_${Date.now()}_${Math.random().toString(36).substr(2, 9)}` } } } </script>2.2 请求防抖与拦截
// 使用axios拦截器实现请求防抖 import axios from'axios' // 存储正在进行的请求 const pendingRequests = newMap() // 生成请求key const generateReqKey = (config) => { const { method, url, params, data } = config return [method, url, JSON.stringify(params), JSON.stringify(data)].join('&') } // 请求拦截器 axios.interceptors.request.use(config => { const key = generateReqKey(config) if (pendingRequests.has(key)) { // 请求已存在，取消当前请求 config.cancelToken = new axios.CancelToken(cancel => { cancel(`重复请求已被拦截: ${key}`) }) } else { // 新请求，添加到pending中 pendingRequests.set(key, config) } return config }) // 响应拦截器 axios.interceptors.response.use( response => { const key = generateReqKey(response.config) pendingRequests.delete(key) return response }, error => { if (axios.isCancel(error)) { console.log('请求被取消:', error.message) returnPromise.reject(error) } // 错误处理完成后，也要从pending中移除 if (error.config) { const key = generateReqKey(error.config) pendingRequests.delete(key) } returnPromise.reject(error) } )前端防护小结：
优点：实现简单，能拦截大部分用户无意识的重复点击
缺点：可被绕过（如直接调用API、禁用JS、使用Postman等工具）
结论：前端防护是必要但不充分的措施，绝不能作为唯一防线
03 第二道防线：后端接口幂等性设计
幂等性是解决重复提交的核心理念。
所谓幂等，就是同一个操作执行多次的结果与执行一次的结果相同。
3.1 什么是幂等性？
对于订单提交接口：
幂等：无论调用1次还是N次，都只创建一个订单
非幂等：调用N次可能创建N个订单
3.2 基于Token的幂等实现
这是最常用的幂等实现方案，流程如下：
客户端在提交前，先向后端申请一个唯一Token
提交订单时携带此Token
服务端检查Token是否已使用过
// 幂等性Token服务 @Service public class IdempotentTokenService { @Autowired private RedisTemplate<String, String> redisTemplate; private static final String IDEMPOTENT_PREFIX = "idempotent:token:"; private static final long TOKEN_EXPIRE_SECONDS = 300; // Token有效期5分钟 /** * 生成幂等性Token * / public String generateToken(String userId) { String token = UUID.randomUUID().toString(); String redisKey = IDEMPOTENT_PREFIX + userId + ":" + token; // 存储Token，设置过期时间 redisTemplate.opsForValue().set( redisKey, "1", TOKEN_EXPIRE_SECONDS, TimeUnit.SECONDS ); return token; } /** * 检查并消费Token * @return true: Token有效且消费成功; false: Token无效或已消费 */ public boolean checkAndConsumeToken(String userId, String token) { String redisKey = IDEMPOTENT_PREFIX + userId + ":" + token; // 使用Lua脚本保证原子性 String luaScript = """ if redis.call('get', KEYS[1]) == '1' then redis.call('del', KEYS[1]) return 1 else return 0 end """; DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>(); redisScript.setScriptText(luaScript); redisScript.setResultType(Long.class); Long result = redisTemplate.execute( redisScript, Collections.singletonList(redisKey) ); return result != null && result == 1L; } } // 使用AOP实现幂等性校验 @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface Idempotent { String key() default ""; // 幂等键，支持SpEL表达式 long expireTime() default 300; // 过期时间，秒 } @Aspect @Component public class IdempotentAspect { @Autowired private RedisTemplate<String, String> redisTemplate; @Around("@annotation(idempotent)") public Object around(ProceedingJoinPoint joinPoint, Idempotent idempotent) throws Throwable { // 1. 获取方法参数 Object[] args = joinPoint.getArgs(); MethodSignature signature = (MethodSignature) joinPoint.getSignature(); Method method = signature.getMethod(); // 2. 解析幂等键（支持SpEL） String keyExpression = idempotent.key(); String redisKey = parseKey(keyExpression, method, args); // 3. 尝试获取分布式锁（防止并发请求同时通过检查） String lockKey = redisKey + ":lock"; boolean lockAcquired = false; try { // 尝试加锁 lockAcquired = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS); if (!lockAcquired) { thrownew BusinessException("系统繁忙，请稍后重试"); } // 4. 检查Token是否已使用 Boolean exists = redisTemplate.hasKey(redisKey); if (Boolean.TRUE.equals(exists)) { // Token已使用，直接返回之前的处理结果（这里需要根据实际业务调整） throw new BusinessException("请勿重复提交订单"); } // 5. 执行业务逻辑 Object result = joinPoint.proceed(); // 6. 标记Token已使用 redisTemplate.opsForValue().set( redisKey, "processed", idempotent.expireTime(), TimeUnit.SECONDS ); return result; } finally { // 释放锁 if (lockAcquired) { redisTemplate.delete(lockKey); } } } private String parseKey(String expression, Method method, Object[] args) { // 这里实现SpEL表达式解析，获取实际的幂等键 // 例如可以从参数中提取userId+orderToken return "parsed:key:from:expression"; } } // 在订单提交接口上使用 @RestController @RequestMapping("/order") public class OrderController { @PostMapping("/submit") @Idempotent(key = "#request.userId + ':' + #request.submitToken", expireTime = 300) public ApiResponse<OrderSubmitResult> submitOrder(@RequestBody OrderSubmitRequest request) { // 这里是真正的订单创建逻辑 OrderSubmitResult result = orderService.createOrder(request); return ApiResponse.success(result); } }3.3 基于唯一业务标识的幂等
除了Token方案，还可以利用业务的自然唯一性实现幂等：
@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Transactional public OrderSubmitResult createOrder(OrderSubmitRequest request) { // 方法1：先查询是否存在 Order existingOrder = orderMapper.selectByUniqueKey( request.getUserId(), request.getProductId(), request.getSubmitTime() ); if (existingOrder != null) { // 订单已存在，直接返回 return convertToResult(existingOrder); } // 方法2：利用数据库唯一约束 try { Order newOrder = buildOrder(request); orderMapper.insert(newOrder); return convertToResult(newOrder); } catch (DuplicateKeyException e) { // 捕获唯一键冲突异常 log.warn("订单重复提交，uniqueKey={}", request.getUniqueKey()); // 查询已创建的订单并返回 Order createdOrder = orderMapper.selectByUniqueKey( request.getUserId(), request.getProductId(), request.getSubmitTime() ); if (createdOrder == null) { throw new BusinessException("订单处理异常，请稍后重试"); } return convertToResult(createdOrder); } } // 订单表可添加唯一索引 // ALTER TABLE t_order ADD UNIQUE KEY uk_user_product_time (user_id, product_id, submit_time); }幂等性设计小结：
Token方案：通用性强，适合大多数场景
业务标识方案：更自然，但依赖业务的天然唯一性
关键点：所有幂等性检查必须在事务开始前完成，否则可能失效
04 第三道防线：数据库层防护
数据库是数据持久化的最后一道关卡，在这里设置防护至关重要。
4.1 唯一约束与乐观锁
-- 订单表设计示例 CREATE TABLE`t_order` ( `id`bigint(20) NOTNULL AUTO_INCREMENT COMMENT'主键', `order_no`varchar(32) NOTNULLCOMMENT'订单号，业务唯一', `user_id`bigint(20) NOTNULLCOMMENT'用户ID', `product_id`bigint(20) NOTNULLCOMMENT'商品ID', `quantity`int(11) NOTNULLCOMMENT'购买数量', `amount`decimal(10,2) NOTNULLCOMMENT'订单金额', `status`tinyint(4) NOTNULLDEFAULT'1'COMMENT'订单状态：1-待支付，2-已支付', `submit_token`varchar(64) DEFAULTNULLCOMMENT'提交Token，用于幂等', `version`int(11) NOTNULLDEFAULT'1'COMMENT'版本号，用于乐观锁', `create_time` datetime NOTNULLDEFAULTCURRENT_TIMESTAMP, `update_time` datetime NOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY`uk_order_no` (`order_no`), -- 订单号唯一 UNIQUE KEY`uk_user_submit_token` (`user_id`, `submit_token`), -- 提交Token唯一 UNIQUE KEY`uk_user_product_time` (`user_id`, `product_id`, `create_time`), -- 业务维度唯一 KEY`idx_user_id` (`user_id`), KEY`idx_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';4.2 数据库层面的幂等实现
// 使用数据库事务+唯一约束保证最终一致性 @Service public class OrderServiceV2 { @Autowired private OrderMapper orderMapper; @Autowired private IdempotentTokenService tokenService; @Transactional(rollbackFor = Exception.class) public OrderSubmitResult submitOrderWithDBProtection(OrderSubmitRequest request) { String userId = request.getUserId(); String submitToken = request.getSubmitToken(); // 1. 检查幂等Token（在事务外先检查一次） if (!tokenService.checkAndConsumeToken(userId, submitToken)) { throw new BusinessException("请勿重复提交订单"); } try { // 2. 生成订单号（雪花算法等分布式ID生成器） String orderNo = generateOrderNo(); // 3. 创建订单对象 Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setProductId(request.getProductId()); order.setQuantity(request.getQuantity()); order.setAmount(calculateAmount(request)); order.setSubmitToken(submitToken); // 4. 插入订单（这里依赖数据库唯一约束） orderMapper.insert(order); // 5. 更新库存等后续操作... updateProductStock(request.getProductId(), request.getQuantity()); returnnew OrderSubmitResult(orderNo, "订单创建成功"); } catch (DuplicateKeyException e) { // 6. 处理唯一约束冲突 log.warn("订单重复提交，userId={}, token={}", userId, submitToken); // 查询已创建的订单 Order existingOrder = orderMapper.selectBySubmitToken(userId, submitToken); if (existingOrder != null) { return new OrderSubmitResult( existingOrder.getOrderNo(), "订单已创建成功，请勿重复提交" ); } // 理论上不会走到这里，除非有极端情况 throw new BusinessException("订单处理异常，请稍后重试"); } } }05 第四道防线：分布式锁
在分布式环境下，多个实例可能同时处理同一个请求，需要分布式锁来保证只有一个实例执行核心逻辑。
5.1 基于Redis的分布式锁
@Component public class DistributedLockService { @Autowired private RedissonClient redissonClient; /** * 尝试获取分布式锁 * @param lockKey 锁的key * @param waitTime 等待时间（毫秒） * @param leaseTime 持有时间（毫秒） * @return 锁对象，获取失败返回null */ public RLock tryLock(String lockKey, long waitTime, long leaseTime) { RLock lock = redissonClient.getLock(lockKey); try { boolean acquired = lock.tryLock(waitTime, leaseTime, TimeUnit.MILLISECONDS); return acquired ? lock : null; } catch (InterruptedException e) { Thread.currentThread().interrupt(); returnnull; } } /** * 订单提交分布式锁 */ public RLock lockForOrderSubmit(String userId, String submitToken) { String lockKey = String.format("order:submit:lock:%s:%s", userId, submitToken); return tryLock(lockKey, 100, 5000); // 等待100ms，锁持有5秒 } } // 在订单服务中使用分布式锁 @Service public class OrderServiceV3 { @Autowired private DistributedLockService lockService; @Autowired private OrderMapper orderMapper; public OrderSubmitResult submitOrderWithDistributedLock(OrderSubmitRequest request) { String userId = request.getUserId(); String submitToken = request.getSubmitToken(); // 1. 获取分布式锁 RLock lock = lockService.lockForOrderSubmit(userId, submitToken); if (lock == null) { throw new BusinessException("系统繁忙，请稍后重试"); } try { // 2. 检查是否已处理 Order existingOrder = orderMapper.selectBySubmitToken(userId, submitToken); if (existingOrder != null) { return new OrderSubmitResult( existingOrder.getOrderNo(), "订单已创建成功，请勿重复提交" ); } // 3. 执行业务逻辑 return doCreateOrder(request); } finally { // 4. 释放锁 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } } private OrderSubmitResult doCreateOrder(OrderSubmitRequest request) { // 实际的订单创建逻辑 // 这里已经保证了同一时刻只有一个线程在处理同一个提交请求 // ... } }5.2 分布式锁的注意事项
使用分布式锁时要注意：
锁粒度：不要太粗（影响性能）也不要太细（增加复杂度）
锁超时：必须设置合理的超时时间，防止死锁
锁续期：对于长时间操作，需要实现锁续期机制
可重入性：同一个线程可以重复获取锁
容错性：Redis集群故障时要有降级方案
06 第五道防线：异步处理与消息队列
对于高并发场景，可以采用异步处理模式，将同步请求转为异步任务。
实现代码示例：
// 异步订单处理实现 @Component public class AsyncOrderService { @Autowired private RocketMQTemplate rocketMQTemplate; @Autowired private RedisTemplate<String, String> redisTemplate; /** * 异步提交订单 */ public AsyncSubmitResult asyncSubmitOrder(OrderSubmitRequest request) { // 1. 生成唯一请求ID String requestId = generateRequestId(request.getUserId()); // 2. 快速验证（库存、用户状态等） quickValidate(request); // 3. 将请求ID与用户关联（用于查询结果） String pendingKey = "order:pending:" + request.getUserId() + ":" + requestId; redisTemplate.opsForValue().set(pendingKey, "processing", 10, TimeUnit.MINUTES); // 4. 发送到消息队列 OrderMessage message = new OrderMessage(); message.setRequestId(requestId); message.setRequest(request); message.setTimestamp(System.currentTimeMillis()); rocketMQTemplate.asyncSend( "ORDER_SUBMIT_TOPIC", message, new SendCallback() { @Override public void onSuccess(SendResult sendResult) { log.info("订单消息发送成功: {}", requestId); } @Override public void onException(Throwable throwable) { log.error("订单消息发送失败: {}", requestId, throwable); // 发送失败，更新状态 redisTemplate.opsForValue().set( pendingKey, "failed", 5, TimeUnit.MINUTES ); } } ); // 5. 立即返回，告知用户处理中 return new AsyncSubmitResult(requestId, "订单提交成功，正在处理中"); } } // 消息消费者 @Component @RocketMQMessageListener( topic = "ORDER_SUBMIT_TOPIC", consumerGroup = "order-submit-consumer-group" ) public class OrderSubmitConsumer implements RocketMQListener<OrderMessage> { @Autowired private OrderMapper orderMapper; @Override public void onMessage(OrderMessage message) { String requestId = message.getRequestId(); OrderSubmitRequest request = message.getRequest(); // 1. 幂等检查（基于requestId） Order existing = orderMapper.selectByRequestId(requestId); if (existing != null) { log.info("订单已处理，跳过: {}", requestId); return; } // 2. 创建订单 Order order = createOrder(request, requestId); try { orderMapper.insert(order); log.info("订单创建成功: {}", order.getOrderNo()); // 3. 更新处理状态 updateProcessingStatus(request.getUserId(), requestId, "success", order.getOrderNo()); } catch (DuplicateKeyException e) { log.warn("订单重复，requestId={}", requestId); // 查询已创建的订单 Order created = orderMapper.selectByRequestId(requestId); if (created != null) { updateProcessingStatus(request.getUserId(), requestId, "success", created.getOrderNo()); } } } }07 综合方案：多层次联合防护
在实际生产环境中，我们通常会采用多层次、立体化的防护策略。
以下是一个完整的综合方案流程图：
这个多层次方案中，每一层都有其特定作用：
前端层：用户体验优化，拦截大部分无意识重复
网关层：安全防护，防刷、限流
业务层：核心幂等逻辑，分布式锁保证并发安全
数据层：最终保障，唯一约束防止数据不一致
异步层：削峰填谷，提升系统吞吐量
08 实战：不同场景下的方案选择
不同的业务场景需要不同的防护策略，这里给出一些实践建议：
8.1 普通电商订单
// 普通电商订单推荐方案 @Service public class StandardOrderService { // 综合使用：前端防抖 + Token幂等 + 数据库唯一约束 public OrderSubmitResult submitStandardOrder(OrderSubmitRequest request) { // 1. 参数校验 validateRequest(request); // 2. 幂等Token检查（Redis） if (!idempotentCheck(request.getUserId(), request.getSubmitToken())) { return getExistingOrderResult(request.getUserId(), request.getSubmitToken()); } // 3. 分布式锁（防并发） RLock lock = acquireOrderLock(request.getUserId(), request.getProductId()); try { // 4. 库存检查等业务校验 checkInventory(request.getProductId(), request.getQuantity()); // 5. 创建订单（依赖数据库唯一约束） return createOrderInTransaction(request); } finally { lock.unlock(); } } }8.2 秒杀订单
// 秒杀订单需要更极致的优化 @Service public class FlashSaleOrderService { // 秒杀方案：异步处理 + 库存预扣 + 最终一致性 public FlashSaleSubmitResult submitFlashSaleOrder(FlashSaleRequest request) { // 1. 验证用户资格和活动状态（缓存中检查） if (!checkUserQualification(request.getUserId(), request.getActivityId())) { throw new BusinessException("您不具备参与资格"); } // 2. 预扣库存（Redis原子操作） boolean stockDeducted = preDeductStock( request.getActivityId(), request.getProductId(), request.getUserId() ); if (!stockDeducted) { throw new BusinessException("库存不足"); } // 3. 生成唯一请求ID String requestId = generateRequestId(request.getUserId(), request.getActivityId()); // 4. 发送到消息队列（快速返回） sendToMQ(request, requestId); // 5. 立即返回 return new FlashSaleSubmitResult(requestId, "秒杀请求已接受，处理中"); } // 消费者异步创建订单 @Transactional public void processFlashSaleOrder(FlashSaleRequest request, String requestId) { // 这里只需要处理真正的订单创建 // 因为库存已在Redis中预扣，只需保证最终一致性 try { createOrder(request, requestId); // 同步库存到数据库 syncStockToDB(request.getProductId(), request.getActivityId()); } catch (Exception e) { // 失败时回滚Redis库存 rollbackStockInRedis(request.getActivityId(), request.getProductId(), request.getUserId()); throw e; } } }10 总结
防止重复提交订单是一个系统工程，需要从前到后、多层次的防护。
让我们回顾一下关键点：
前端防护是体验，不是保障：按钮防抖、请求拦截能改善用户体验，但不能作为唯一防线。
幂等性是核心理念：无论是Token方案还是业务唯一标识，都要保证同一操作执行多次的结果一致。
分布式锁解决并发问题：在分布式环境下，防止多个实例同时处理同一请求。
数据库是最后防线：唯一约束、乐观锁等机制能在应用层防护失效时保证数据一致性。
异步处理提升吞吐：对于高并发场景，将同步请求转为异步处理，提高系统整体吞吐量。
监控告警必不可少：没有监控的系统就像没有仪表的飞机，无法发现问题和优化性能。
在实际架构设计中，我通常建议采用"前端防抖 + 网关限流 + Token幂等 + 分布式锁 + 数据库唯一约束"的综合方案，对于秒杀等极致场景再加入异步处理。
有些小伙伴可能会觉得这些防护措施太复杂，影响开发效率。
但请记住：预防的成本远低于修复的成本。
一次重复提交导致的资损事故，可能就需要整个团队加班数周来修复数据和安抚用户。
技术方案没有银弹，只有最适合业务场景的平衡。
（支持资料、图片参考_相关定制）_文章底部可以扫码)
