DDD聚合场景下维护StockItem库存水平的最优实现方案咨询

自动重试的合理性 #

• 首先可以明确：你的场景下捕获乐观并发异常后自动重试是完全合理的，但要满足两个前提：
  • 操作本身是幂等的：库存变更是基于增量的操作，重试时只要重新读取最新的StockLevel值再计算更新，不会出现重复扣减/重复增加的问题
  • 配置合理的重试策略：不要无限重试，建议最多重试3~5次，搭配指数退避策略，避免高并发下大量重试请求压垮数据库
• 乐观并发本身就是为低冲突场景设计的，如果你的业务中同一个商品的库存并发变更概率不高，重试机制完全可以做到用户无感知，不会影响使用体验。

更优的实现方案 #

你完全可以从根源上避免并发冲突，不需要依赖乐观并发和重试机制，推荐两种更稳妥的方案：

方案1：数据库层面原子更新（优先推荐） #

不要走「先查询StockItem得到当前StockLevel -> 内存计算新值 -> 保存回数据库」的路径，直接通过EF执行带增量的SQL更新语句，整个操作是数据库层面的原子操作，自动加行锁，不会有并发问题：

// 假设变动值为changeAmount，正数为加库存，负数为减库存
context.Database.ExecuteSqlInterpolated(
    $"UPDATE StockItem SET StockLevel = StockLevel + {changeAmount} WHERE Id = {stockItemId}"
);

注意要把「新增StockMovement记录」和「更新StockLevel」放在同一个事务中执行，保证数据一致性，避免出现只有变动记录没有更新库存，或者反过来的情况。

方案2：队列串行化处理 #

如果你的业务库存并发变更概率极高（比如电商秒杀场景），可以把所有库存变更请求写入内存队列或者MQ，用单线程/固定少量线程串行消费处理，从根源上消除并发冲突，不过普通库存场景下这个方案属于过度设计，优先用原子更新即可。

内容的提问来源于stack exchange，提问作者Neil W