带库存校验的加入购物车功能设计及高并发场景解决方案咨询

方案有效性评估 #

你提到的三种方案均能满足「仅10次请求成功、无超卖」的基础要求，三者的适用场景和优劣势如下：

• 悲观锁方案：通过行锁锁住对应商品的库存记录，保证同一时间只有一个请求能更新库存，完全杜绝超卖。但锁等待时间长，并发量较高时会出现大量请求阻塞、超时，仅适合低并发的普通购物场景，无法适配秒杀类流量尖刺场景。
• 乐观锁方案：通过版本号校验或者直接在校验条件里判断库存充足才执行扣减，对应的更新SQL示例为UPDATE product_inventory SET quantity = quantity -1 WHERE product_id = ? AND quantity >=1，无需等待锁，性能远高于悲观锁，少量重试也能提升合法请求的成功率。但当并发量达到数千以上时，大量重试请求会给数据库造成额外压力，容易出现数据库性能瓶颈。
• 前置触发器校验：逻辑上和乐观锁的库存校验等价，能从数据库层拦截所有非法的库存扣减操作，但业务逻辑耦合在数据库层，可维护性极差，后续调整库存规则需要修改触发器，工业界几乎不会选用这种实现。

高并发秒杀场景的加购/库存扣减方案 #

线上秒杀场景的核心思路是分层拦截流量，尽量把请求挡在上层，避免流量直接打到数据库，通用实现逻辑如下：

1. 前端+网关层限流：同一用户、同一IP短时间内的重复请求直接在前端或者接入网关层拦截返回，先过滤掉90%以上的无效流量，不用进入后端服务处理。
2. 缓存层预扣库存：热点商品的库存提前预热到Redis中，利用Redis单线程的原子操作做库存预扣，调用DECR命令扣减对应商品的库存key，返回结果大于等于0则代表预扣成功，允许进入后续流程，否则直接返回库存不足。Redis单实例就能扛住每秒10万级别的请求，完全可以承接秒杀的流量峰值。
3. 异步落库保证最终一致：Redis预扣成功后，不用同步更新数据库，把扣减请求发送到消息队列，后端消费进程异步消费更新数据库的实际库存，同时后台定时做Redis和数据库的库存对账，保证两边数据最终一致即可。
4. 数据库兜底校验：数据库层还是保留乐观锁的校验逻辑作为最后一道防线，就算前面的缓存逻辑出现异常，也不会出现超卖的问题。

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