高并发电商系统订单与库存协同优化实践

发布时间：2026/11/2 14:27:39
高并发电商系统订单与库存协同优化实践

1. 高并发场景下的订单与库存挑战

电商大促期间，系统每秒要处理上万笔订单，库存数据在毫秒级内被反复修改。去年双十一，某平台前5分钟就产生了800万笔交易，但库存超卖问题导致后续客诉激增——这就是典型的高并发场景下订单与库存的协同难题。

订单和库存作为电商系统的核心模块，其数据处理需要满足三个刚性需求：原子性（要么全部成功要么全部失败）、一致性（库存扣减与订单创建必须同步）、隔离性（并发请求不能互相干扰）。传统单体架构下，我们可能直接用数据库事务处理，但在分布式系统中，这会导致严重的性能瓶颈。

2. 分布式锁的选型与实践

2.1 主流分布式锁方案对比

当多个服务实例同时修改同一商品库存时，我们需要可靠的分布式锁机制。以下是三种典型方案的实测数据（基于1000并发测试）：

方案类型平均响应时间死锁风险实现复杂度适用场景
Redis SETNX12ms低简单短时高频操作
Zookeeper临时节点45ms无中等强一致性要求
数据库行锁120ms中简单已有数据库依赖的系统

2.2 Redis分布式锁的优化实现

// 改进版的Redis锁实现 public boolean tryLock(String lockKey, String requestId, int expireTime) { return redisTemplate.execute((RedisCallback<Boolean>) connection -> { // 使用SET NX EX命令保证原子性 String result = connection.execute("SET", lockKey.getBytes(), requestId.getBytes(), "NX".getBytes(), "EX".getBytes(), String.valueOf(expireTime).getBytes()); return "OK".equals(result); }); } // 解锁时必须验证requestId防止误删 public boolean unlock(String lockKey, String requestId) { String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " + "return redis.call('del', KEYS[1]) " + "else return 0 end"; return redisTemplate.execute( new DefaultRedisScript<Long>(script, Long.class), Collections.singletonList(lockKey), requestId) == 1; }

关键细节：必须设置过期时间（建议5-30秒）并实现锁续期机制。我们在生产环境使用Redisson的watchDog机制，每10秒检查一次业务是否完成，自动延长锁持有时间。

3. 库存扣减的最终一致性方案

3.1 预扣库存模式设计

采用"预扣+确认"两阶段方案，大幅降低锁持有时间：

  1. 预扣阶段（50ms内完成）：

    • 检查库存是否充足
    • 在Redis中执行DECR操作
    • 记录预扣日志（含用户ID、商品ID、预扣数量）

  2. 确认阶段（异步处理）：

    • 订单创建成功后更新数据库库存
    • 失败时通过定时任务恢复Redis库存
-- 库存表设计关键字段 CREATE TABLE `inventory` ( `item_id` bigint NOT NULL COMMENT '商品ID', `total_stock` int NOT NULL COMMENT '总库存', `locked_stock` int NOT NULL DEFAULT '0' COMMENT '预扣库存', `available_stock` int GENERATED ALWAYS AS (`total_stock` - `locked_stock`) VIRTUAL, PRIMARY KEY (`item_id`) ) ENGINE=InnoDB;

3.2 库存防超卖的实现要点

  1. Redis库存校验：

    -- 原子化校验库存脚本 local stock = tonumber(redis.call('GET', KEYS[1])) if stock >= tonumber(ARGV[1]) then return redis.call('DECRBY', KEYS[1], ARGV[1]) else return -1 end

  2. 数据库更新策略：

    UPDATE inventory SET locked_stock = locked_stock + #{num} WHERE item_id = #{itemId} AND (total_stock - locked_stock) >= #{num}

  3. 异常处理机制：

    • 网络超时采用异步补偿
    • 双重扣减时使用唯一流水号幂等控制

4. 订单创建的异步化处理

4.1 基于消息队列的订单流水线

[用户请求] → [库存预扣] → [订单创建事件] → [支付服务] ↓ ↓ [库存回滚队列] [订单超时取消队列]

采用RocketMQ的事务消息保证流程可靠性：

  1. 发送半消息到MQ Server
  2. 执行本地事务（创建订单记录）
  3. 根据本地事务结果提交或回滚消息

4.2 订单分库分表策略

按用户ID哈希分片，解决热点问题：

// 分片键计算公式 int shardNo = Math.abs(userId.hashCode()) % 1024; String tableName = "order_" + shardNo / 64; // 每库64张表

实战经验：大促前通过历史数据预测，对热门商品提前进行库存分片（如将iPhone库存按颜色版本拆分到不同库存ID）

5. 容灾与降级方案

5.1 多级缓存策略

  1. L1缓存：本地Caffeine（有效期5秒）
  2. L2缓存：Redis集群（有效期30秒）
  3. 降级策略：
    • 缓存击穿：使用BloomFilter过滤无效请求
    • 缓存雪崩：采用阶梯过期时间（基础时间±随机浮动）

5.2 限流熔断配置

# Sentinel配置示例 spring: cloud: sentinel: filter: url-patterns: /** datasource: ds1: nacos: server-addr: localhost:8848 dataId: sentinel-rules rule-type: flow

熔断策略建议：

  • 慢调用比例（>500ms视为慢调用）
  • 异常比例阈值（超过50%持续5秒触发熔断）

6. 性能优化实战案例

某家电平台在实施以下优化后，峰值QPS从2000提升至12000：

  1. 库存热点分离：

    • 将SKU库存数据按地域拆分
    • 热门商品预分片（如1000台iPhone拆分为10个虚拟库存单元）

  2. 订单批量提交：

    // 合并5ms内的请求 @Scheduled(fixedDelay = 5) public void batchCreateOrders() { List<Order> batch = orderQueue.drain(100); jdbcTemplate.batchUpdate("INSERT...", batch); }

  3. 数据库优化：

    • 使用ClickHouse处理订单分析
    • MySQL配置innodb_flush_log_at_trx_commit=2（牺牲部分持久性换取性能）

这套方案在去年双十一期间经受住了实战检验，核心链路零故障，库存差异率控制在0.003%以内。真正的挑战往往在于异常情况处理——比如某次机房网络中断导致Redis集群脑裂，我们通过预先设计的本地库存应急模式保证了基本下单功能。