java 高并发商城库存订单处理,下单减库存，如何解决高并发减库存问题

下单减库存，如何解决高并发减库存问题

1. 减库存

一般下单减库存的流程大概是这样的：

1、查询商品库存。这里直接查的Redis中的库存。

2、Redis中的库存减1。这里用到的Redis命令是：incrby -1

3、扣减数据库中的库存。这里用数据库乐观锁，不用额外加锁

4、异步刷新Redis中的库存

5、定时扫描超时未支付的交易，库存加回去

总结一下这个流程就是：先减redis库存，再减数据库库存，最后刷新redis库存

用到的Redis命令可能：DECR key  或者  INCRBY key -1

更新数据库的SQL可能是这样的：

update 商品库存表 set 库存 = 库存 - 1 where 商品ID = xxx and 库存 > 0;

或者

update 商品库存表 set 库存 = 库存 - 1 where 商品ID = xxx and version = xxx;

用乐观锁是一种比较好的方式，而且一遍ID字段都有索引，可以充分利用MySQL行级锁

这种方式还有一个比较巧妙的地方是，利用redis的单线程来操作库存，而且又是原子命令，可以避免并发问题

同时，先减redis库存后可以防止后续因库存不足而造成下单失败

最后，数据库更新完以后，再通过MQ异步刷新缓存，可以使得redis中的库存误差不会太大

交易系统会定时扫描超时未支付的订单，然后用MQ异步通知订单和商品中心，将订单关闭，库存再放回去

2. 加锁

加锁(比如：基于Redis的分布式锁)

MQ可以把并行转成串行，但是并不能很好的解决并发访问的问题，只能靠锁

加锁会影响性能，但是影响不大。假设我们用Redisson分布式锁，操作redis只需要几毫秒，因此这点儿损耗不是什么大问题。都是这么玩儿的，不加锁还能怎么办呢。

3. 内存缓存

在cms管理后台修改数据后，同步或异步刷新redis缓存，同时利用zookeeper刷新内存缓存，这样就可以不用等到需要用的时候再从redis中同步。

一定要避免redis大key，最常见的就是hash key，设置的时候不注意，一不小心里面就几千个field了，这对查询非常不利，可以取模进行分片。

一定要避免HGETALL命令，利用Pinpoint可以帮助我们分析每个请求在每个操作所消耗的时候，从而有助于我们优化

数据迁移用Canal

https://redis.io/commands/incr

相关文章暂无相关文章