电商订单系统设计：Java高并发与分布式事务实战

鄂奎阿

246人浏览 · 2026-08-07 11:00:15

鄂奎阿 · 2026-08-07 11:00:15 发布

1. 为什么电商订单系统是Java面试的经典考题

电商订单处理系统作为Java技术栈的"集大成者"，几乎涵盖了企业级开发的所有核心要素。从我的面试官经历来看，这套系统能全面考察候选人的技术广度与深度。订单系统看似简单，实则暗藏玄机——它需要处理高并发写入、保证数据一致性、实现分布式事务，还要应对秒杀等极端场景。

大厂特别青睐这类考题的原因有三：首先，电商业务与公司营收直接挂钩，系统稳定性至关重要；其次，订单系统涉及的技术栈与公司实际技术架构高度吻合；最后，这类系统有足够的复杂度来区分候选人水平。我曾见过两位候选人对同一个订单超卖问题给出截然不同的解决方案，这正是面试官想看到的思维差异。

2. 订单系统的核心模块拆解

2.1 订单状态机设计

订单状态流转是系统的核心逻辑。一个健壮的状态机应该具备：

public enum OrderStatus {
    CREATED(1), 
    PAID(2),
    SHIPPED(3),
    COMPLETED(4),
    CANCELLED(5),
    REFUNDED(6);
    
    // 状态流转规则
    private static final Map<OrderStatus, Set<OrderStatus>> allowedTransitions = Map.of(
        CREATED, Set.of(PAID, CANCELLED),
        PAID, Set.of(SHIPPED, REFUNDED),
        SHIPPED, Set.of(COMPLETED, REFUNDED)
    );
    
    public static boolean canTransition(OrderStatus from, OrderStatus to) {
        return allowedTransitions.getOrDefault(from, Set.of()).contains(to);
    }
}

关键点：状态变更必须通过统一入口进行校验，避免出现"已取消的订单又被发货"这类业务异常。建议采用状态模式(State Pattern)实现，每个状态对应一个处理类。

2.2 分布式ID生成方案

订单号作为系统唯一标识，需要满足：

全局唯一
趋势递增（利于数据库索引）
高可用（避免单点故障）

Snowflake算法是常见选择，但在容器化环境需要注意workerId的分配问题。我们改进的方案是：

public class DistributedIdGenerator {
    private static final long START_TIMESTAMP = 1609459200000L; // 2021-01-01
    private static final long WORKER_ID_BITS = 10L;
    private static final long SEQUENCE_BITS = 12L;
    
    private long workerId;
    private long sequence = 0L;
    private long lastTimestamp = -1L;
    
    public synchronized long nextId() {
        long timestamp = timeGen();
        if (timestamp < lastTimestamp) {
            throw new RuntimeException("时钟回拨异常");
        }
        
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & ((1 << SEQUENCE_BITS) - 1);
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }
        
        lastTimestamp = timestamp;
        return ((timestamp - START_TIMESTAMP) << (WORKER_ID_BITS + SEQUENCE_BITS))
                | (workerId << SEQUENCE_BITS)
                | sequence;
    }
    
    // 动态获取workerId（基于K8s StatefulSet的hostname）
    private void initWorkerId() {
        String hostname = System.getenv("HOSTNAME");
        this.workerId = Long.parseLong(hostname.substring(hostname.lastIndexOf("-") + 1));
    }
}

3. 高并发下的技术应对策略

3.1 库存扣减方案对比

方案	实现复杂度	性能	一致性	适用场景
数据库悲观锁	低	差	强	低频次商品
乐观锁+版本号	中	中	最终	常规秒杀
Redis原子操作	高	极好	弱	超高并发秒杀
预扣库存+异步确认	极高	好	最终	大促活动

实际项目中，我们采用分级策略：

前端限流：按钮置灰+随机延迟
网关层：令牌桶限流
服务层：Redis Lua脚本扣减

local stock = tonumber(redis.call('GET', KEYS[1]))
if stock <= 0 then
    return 0
end
if stock >= tonumber(ARGV[1]) then
    redis.call('DECRBY', KEYS[1], ARGV[1])
    return 1
end
return 0

持久层：最终通过MQ异步同步到数据库

3.2 分布式事务实践

订单创建涉及多个服务调用：

扣减库存
生成订单
创建支付单

我们采用Seata的AT模式实现：

@GlobalTransactional
public Order createOrder(OrderDTO orderDTO) {
    // 1. 扣减库存
    inventoryService.reduceStock(orderDTO.getSkuId(), orderDTO.getQuantity());
    
    // 2. 创建订单
    Order order = convertToOrder(orderDTO);
    orderMapper.insert(order);
    
    // 3. 创建支付单
    paymentService.createPayment(order.getOrderNo(), order.getAmount());
    
    return order;
}

避坑指南：Seata的全局锁默认超时时间是60秒，对于长事务需要调整 client.tm.degrade-check-period 参数。我们曾在促销活动时因为事务超时导致大量订单卡在"处理中"状态。

4. 典型面试问题深度解析

4.1 订单分库分表策略

当订单表达到千万级时，需要考虑分片。我们的分片键选择经历了三个阶段：

初期：按用户ID哈希分片
- 优点：用户查询体验好
- 缺点：大客户数据集中导致热点
中期：时间范围+用户ID复合分片
- 按季度分库，用户ID哈希分表
- 需要处理跨库查询问题
当前：基因法分片
- 从用户ID提取基因片段融入订单号
- 既能分散数据，又保证同一用户数据相对集中

分片后订单号改造示例：

原订单号：20230809123456
改造后：09(用户基因)20230809123456

4.2 支付回调处理

支付回调是订单系统的关键路径，必须处理好以下问题：

幂等性：通过唯一事务号+状态机校验
并发控制：数据库行锁+乐观锁
补偿机制：定时任务扫描待支付订单

我们的回调处理流程：

@Transactional
public void handlePaymentCallback(PaymentNotifyDTO notify) {
    // 1. 幂等校验
    Order order = orderMapper.selectByOrderNo(notify.getOrderNo());
    if (order.getStatus() != OrderStatus.CREATED) {
        log.warn("订单已处理: {}", notify.getOrderNo());
        return;
    }
    
    // 2. 更新订单状态
    int updated = orderMapper.updateStatus(
        notify.getOrderNo(), 
        OrderStatus.CREATED, 
        OrderStatus.PAID
    );
    if (updated == 0) {
        throw new OptimisticLockException("订单状态变更冲突");
    }
    
    // 3. 触发后续流程
    eventPublisher.publishEvent(new OrderPaidEvent(order));
}

5. 性能优化实战技巧

5.1 查询优化方案

订单列表查询的典型痛点：

多表关联（用户信息、商品快照等）
复杂筛选条件（时间范围、状态、关键词等）

我们的解决方案：

使用Elasticsearch构建订单宽表
- 通过Logstash同步MySQL数据
- 对常用字段建立组合索引
分页优化
- 避免 LIMIT 10000,10 式分页
- 改用游标分页：

SELECT * FROM orders 
WHERE id > ? AND status = ? 
ORDER BY id ASC LIMIT 10

冷热数据分离
- 3个月前的订单归档到Tidb

5.2 JVM参数调优

订单系统的GC优化经验：

对象特点：
- 大量短生命周期的DTO对象
- 订单缓存对象存活时间中等
关键参数：

-XX:+UseG1GC 
-XX:MaxGCPauseMillis=200 
-XX:InitiatingHeapOccupancyPercent=45
-XX:NewRatio=2 
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=15

监控发现：
- Young GC频繁 → 增大Eden区
- CMS失败 → 切换G1收集器
- 大对象分配失败 → 调整Region大小

6. 全栈视角下的系统设计

6.1 前端优化策略

订单提交防重复：
- 按钮点击后禁用
- 本地生成临时订单ID
- 请求失败自动重试机制
长轮询查询状态：

function checkOrderStatus(orderNo) {
    const poll = () => {
        fetch(`/api/orders/${orderNo}/status`)
            .then(res => {
                if (res.status === 'completed') {
                    // 跳转结果页
                } else {
                    setTimeout(poll, 2000); 
                }
            });
    };
    poll();
}