电商补货系统实战：基于事件驱动的补货skill架构设计与优化

4次阅读

共计 1813 个字符，预计需要花费 5 分钟才能阅读完成。

在高并发电商场景下，传统的同步补货接口面临诸多挑战：

性能瓶颈 ：同步阻塞式调用导致系统吞吐量急剧下降，尤其在秒杀活动期间，补货请求激增时服务响应时间呈指数级增长。
库存竞争 ：超卖问题频发，当多个补货请求同时到达时，基于数据库行锁的库存扣减方案会产生大量死锁和超时。
数据一致性 ：补货操作与库存更新、订单创建等操作缺乏事务隔离，可能出现部分成功导致的脏数据。

采用发布 - 订阅模式解耦补货流程：

事件总线 ：通过 Kafka 实现补货事件的异步传输，生产者和消费者完全隔离。
状态管理 ：每个补货请求被建模为状态机，包含四个核心状态：
待处理（PENDING）
执行中（PROCESSING）
已完成（COMPLETED）
失败（FAILED）
数据存储 ：
Redis：分布式锁 + 库存缓存
MySQL：最终一致性存储

@RestController
public class ReplenishmentController {
    @Autowired
    private KafkaTemplate<String, ReplenishmentEvent> kafkaTemplate;

    @PostMapping("/replenish")
    public ResponseEntity<String> triggerReplenishment(@RequestBody ReplenishmentRequest request) {
        // 生成唯一事件 ID
        String eventId = UUID.randomUUID().toString();

        // 构建补货事件
        ReplenishmentEvent event = new ReplenishmentEvent(
            eventId,
            request.getSkuCode(),
            request.getQuantity(),
            System.currentTimeMillis());

        // 发送到 Kafka
        kafkaTemplate.send("replenishment-topic", event);

        return ResponseEntity.ok("补货请求已受理");
    }
}

@Service
public class ReplenishmentConsumer {
    @Autowired
    private RedissonClient redissonClient;

    @KafkaListener(topics = "replenishment-topic")
    public void consume(ReplenishmentEvent event) {
        // 获取分布式锁
        RLock lock = redissonClient.getLock("lock:sku:" + event.getSkuCode());

        try {
            // 尝试加锁，最多等待 3 秒，锁定 30 秒
            if (lock.tryLock(3, 30, TimeUnit.SECONDS)) {
                // 执行补货逻辑
                processReplenishment(event);
            }
        } catch (InterruptedException e) {Thread.currentThread().interrupt();
            // 记录失败并触发补偿
            handleFailure(event);
        } finally {
            // 确保锁被释放
            if (lock.isHeldByCurrentThread()) {lock.unlock();
            }
        }
    }
}