京东大佬问我,10wqps高并发，如何防止重复提交/支付订单？源码下载

这个问题看起来挺常见的，但处理起来需要考虑很多方面。首先，我得先理解问题场景。重复提交可能出现在用户多次点击提交按钮，或者网络问题导致客户端重复发送请求。而支付订单的重复可能涉及第三方支付接口的回调问题。

首先，前端的防重措施可能是第一步。比如，提交按钮点击后禁用，或者显示加载状态，防止用户多次点击。但前端措施不可靠，毕竟用户可以绕过，或者网络问题导致请求重复发送。所以后端必须要有更可靠的机制。

接下来想到的是幂等性设计。每个请求带上唯一标识，比如订单ID或者token，服务端检查这个标识是否已处理过。如果是，就直接返回之前的处理结果，避免重复处理。这里的关键是如何生成这个唯一标识，比如前端生成UUID，或者服务端预先生成token，提交时携带。

然后是分布式锁。在高并发场景下，可能需要用Redis或者ZooKeeper这样的分布式锁来保证同一订单同一时间只有一个请求被处理。比如，当用户提交订单时，先获取订单ID对应的锁，处理完再释放。但要注意锁的粒度，太细可能影响性能，太粗又可能达不到效果。另外，锁的超时时间设置也很关键，防止死锁。

数据库层面的唯一约束也是一种方法。比如订单表里的订单号设置唯一索引，这样即使重复插入也会失败。但这种方法可能在高并发下有大量冲突，导致数据库压力大，需要结合其他方法使用。

状态机机制也很重要。订单状态的变化应该是单向且有状态的，比如从“待支付”到“已支付”，在处理支付回调时，先检查当前状态，如果已经是已支付，就不再处理。这样可以避免重复更新。

支付回调的处理需要特别注意，第三方支付平台可能会多次回调，因此需要保证回调处理的幂等性。可以在处理回调时，先查询订单状态，如果已经成功，就直接返回成功，不再执行后续逻辑。

另外，需要考虑请求的时序问题。比如，先来的请求可能因为网络延迟晚于后来的请求到达，这时候需要服务端有能力处理这种情况，可能需要版本号或者时间戳来判断请求的先后顺序。

还有，日志和监控也是必要的。记录每个请求的详细信息，方便后续排查问题。监控重复请求的发生情况，及时调整防重策略。

最后，需要考虑系统的整体性能和可用性。比如，使用Redis做幂等性检查可能会增加响应时间，需要评估Redis集群的性能是否能够支撑10万QPS。可能需要采用本地缓存结合分布式缓存的策略，或者优化键的设计，减少查询时间。

总结起来，可能需要综合使用前端防重、幂等性设计、分布式锁、数据库唯一约束、状态机等多种手段，同时结合具体业务场景进行优化，比如支付流程中的各个环节如何保证幂等，以及如何高效处理高并发下的请求冲突。

在高并发场景下防止重复提交或支付订单，需要从前端到后端、从应用到数据库的全链路设计。以下是分层次的解决方案：

一、前端防重策略

1. 按钮防抖（Debounce）
2. 提交后立即禁用按钮，直到收到响应或超时
3. 使用CSS禁用状态+Loading动画提升用户体验
4. 客户端幂等令牌
5. 页面加载时预生成唯一Token（UUID或Snowflake ID）
6. 提交时携带Token，服务端验证后立即失效
7. 请求合并
8. 短时间内的重复请求在前端合并为单个请求

二、网络层拦截

1. Nginx限流

 limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
location /api/order {
    limit_req zone=api_limit burst=50 nodelay;
}

2. API网关层
3. 分布式限流（令牌桶/漏桶算法）
4. Header指纹校验（设备ID+时间戳签名）

三、服务端核心防御

1.幂等性设计（关键）

• 方案一：Token机制

 // 预生成Token存入Redis（设置5分钟过期）
String token = UUID.randomUUID().toString();
redis.setex("order:token:"+userId, 300, token);

// 提交时验证并删除
String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
Long result = redis.eval(script, Collections.singletonList("order:token:"+userId), Collections.singletonList(token));
if(result == 0) throw new RepeatSubmitException();

• 方案二：业务唯一键

ALTER TABLE orders ADD UNIQUE KEY uniq_order_no (order_no);

• 插入前先做SELECT检查，异常时捕获DuplicateKeyException

2.分布式锁控制

String lockKey = "order_lock:" + orderId;
// Redisson实现（推荐）
RLock lock = redisson.getLock(lockKey);
try {
    if(lock.tryLock(0, 30, TimeUnit.SECONDS)) {
        // 处理核心业务逻辑
    }
} finally {
    lock.unlock();
}

3.状态机校验

// 使用乐观锁保证状态变更原子性
update orders set status=2 where order_id=1001 and status=1;
if(affectedRows == 0){
    // 状态已变更，直接返回结果
}

4.支付回调处理

// 使用本地事务表保证幂等
@Transactional
public void handlePayNotify(String orderNo, String transactionId) {
    // 1. 检查本地去重表
    if(dupCheckDao.exists(orderNo, transactionId)) return;
    
    // 2. 处理支付成功逻辑
    orderService.updateOrderPaid(orderNo);
    
    // 3. 插入去重记录
    dupCheckDao.insert(orderNo, transactionId);
}

四、存储层优化

1. 数据库读写分离
2. 写操作走主库，读操作走从库
3. 支付状态变更强制走主库查询
4. 异步队列削峰

     // RocketMQ事务消息方案
TransactionMQProducer producer = new TransactionMQProducer("group");
producer.sendMessageInTransaction(msg, new LocalTransactionExecutor());

五、监控与兜底

1. 实时监控报警
2. 监控重复提交率、订单异常率
3. 设置熔断阈值（如1%异常触发熔断）
4. 定时对账系统
5. 每小时扫描异常订单
6. 与支付系统对账，自动修正状态
7. 人工干预接口
8. 提供订单状态强制修正接口
9. 操作记录留痕+二次确认

架构图示意

客户端 → Nginx限流 → API网关 → 服务集群
                ↓              ↓
              Redis集群     DB集群（主从+分库）
                ↑              ↑
             分布式锁      定时对账Job

关键权衡点

1. 性能 vs 安全性
2. 强一致性方案用Redis事务锁（性能损耗约5-10% QPS）
3. 最终一致性方案用DB唯一约束+异步补偿（更高吞吐）
4. 成本考量
5. 10万QPS需Redis Cluster（16节点左右）
6. 分库分表策略（按用户ID哈希分128库）

通过组合前端交互优化、服务端幂等设计、分布式锁、异步化处理等多层防御，可有效应对高并发下的重复提交问题。实际落地时需要根据业务特性选择合适的技术组合。