如何设计高并发下的订单幂等处理？

Question

在高并发场景下，用户重复提交订单或消息中间件重试可能导致订单重复创建。如何基于唯一幂等键（如用户ID+商品ID+时间戳）结合分布式锁与数据库唯一索引，设计高效且低延迟的幂等处理机制？需兼顾系统性能与数据一致性，避免锁竞争严重或唯一约束冲突频发，同时支持水平扩展。

Answer 1

高并发场景下基于唯一幂等键的订单防重机制设计

1. 问题背景与挑战分析

在电商、支付、秒杀等高并发系统中，用户重复提交订单或消息中间件因网络抖动、超时等原因触发重试机制，极易导致订单被重复创建。这不仅破坏了数据一致性，还可能引发财务损失和用户体验下降。

常见的解决方案包括：

• 前端防重（不可靠，易绕过）
• Token机制（需配合后端状态管理）
• 数据库唯一索引约束
• 分布式锁控制执行流程

然而，在百万级QPS场景下，单一手段难以兼顾性能与一致性。本文将从基础到进阶，构建一个融合唯一幂等键 + 分布式锁 + 数据库唯一索引的高效防重体系。

2. 核心概念解析

术语	定义	作用
幂等性	同一操作多次执行结果一致	防止重复下单
幂等键	user_id + product_id + timestamp（精确到秒）	标识唯一请求
分布式锁	Redis/ZooKeeper实现跨节点互斥	避免并发写冲突
唯一索引	DB层强制保证记录唯一性	最终一致性兜底
水平扩展	无状态服务可动态扩容	支撑高并发

3. 方案设计：三层防护模型

1. 第一层：缓存级幂等判断（最快路径） —— 使用Redis判断幂等键是否已存在
2. 第二层：分布式锁竞争（临界区保护） —— 只有未命中的请求才获取锁进入处理逻辑
3. 第三层：数据库唯一索引（最终保障） —— 写入时依赖MySQL唯一索引拦截异常写入

// 示例：Java伪代码实现
public String createOrder(OrderRequest req) {
    String idempotentKey = req.getUserId() + ":" + req.getProductId() + ":" + req.getTimestamp();

    // Layer 1: Cache Check (Fast-Fail)
    if (redis.hasKey(idempotentKey)) {
        return "DUPLICATE";
    }

    // Layer 2: Acquire Distributed Lock
    String lockKey = "lock:" + idempotentKey;
    RLock lock = redisson.getLock(lockKey);
    boolean isLocked = lock.tryLock(1, 5, TimeUnit.SECONDS);
    if (!isLocked) {
        throw new ServiceBusyException();
    }

    try {
        // Double-check in case another thread just inserted
        if (orderMapper.selectByUniqueKey(idempotentKey) != null) {
            return "DUPLICATE";
        }

        // Layer 3: DB Insert with Unique Constraint
        Order order = new Order();
        order.setIdempotentKey(idempotentKey);
        order.setUserId(req.getUserId());
        order.setProductId(req.getProductId());
        order.setCreateTime(new Date());
        orderMapper.insert(order);

        // Set cache for fast fail next time
        redis.setex(idempotentKey, 3600, "1");

        return "SUCCESS";
    } finally {
        lock.unlock();
    }
}

4. 高并发优化策略

为避免锁竞争严重和唯一约束频繁抛出异常，引入以下优化：

• 异步清理机制：订单完成后通过MQ异步删除Redis中的幂等键，减少内存占用
• 时间窗口截断：timestamp只保留到分钟级，降低键空间维度，避免过度碎片化
• 热点商品隔离：对爆款商品使用独立的分片策略，防止单一Redis节点成为瓶颈
• 失败降级处理：当Redis不可用时，降级为仅依赖数据库唯一索引+重试机制

5. 系统架构流程图

graph TD
    A[接收订单请求] --> B{Redis是否存在幂等键?}
    B -- 是 --> C[返回重复提交]
    B -- 否 --> D[尝试获取分布式锁]
    D --> E{获取锁成功?}
    E -- 否 --> F[返回系统繁忙]
    E -- 是 --> G[二次检查DB是否存在]
    G --> H{订单已存在?}
    H -- 是 --> I[释放锁并返回重复]
    H -- 否 --> J[执行订单创建]
    J --> K[插入DB(唯一索引)]
    K --> L[设置Redis缓存]
    L --> M[返回成功]
    style B fill:#cff,stroke:#333
    style D fill:#fdd,stroke:#333
    style K fill:#dfd,stroke:#333

6. 数据一致性与扩展性保障

该方案支持水平扩展的关键在于：

• 服务无状态，可通过K8s自动扩缩容
• Redis集群分片存储幂等键，负载均衡
• 数据库按用户ID哈希分库分表，避免单点写压力
• 消息队列解耦后续流程（如库存扣减），提升整体吞吐量

同时通过本地事务+最终一致性模式确保数据可靠：

1. 订单主表与幂等键表在同一数据库事务中提交
2. 成功后发送MQ事件通知下游系统
3. 消费方幂等地处理事件（同样使用幂等键去重）