每秒上千订单场景下的分布式锁高并发优化

库存超卖:

加锁解决库存超卖:

分布式锁一旦加了之后,对同一商品的下单请求,会导致所有客户端都必须对同一商品的库存锁key进行加锁,这样会导致对同一商品的下单请求是串行化,一个接一个处理.

解决方案:分段加锁

把数据分成很多个段,每个段是一个单独的锁,所以多个线程过来并发修改数据的时候,可以并发的修改不同段的数据.不至于说,同一时间只能有一个线程独占修改ConcurrentHashMap中的数据.

Java8中新增一个LongAdder类,采用类似的分段CAS操作,失败则自动迁移到下一个分段进行CAS思想.

其实这就是分段加锁。你想，假如你现在iphone有1000个库存，那么你完全可以给拆成20个库存段，要是你愿意，可以在数据库的表里建20个库存字段，比如stock_01，stock_02，类似这样的，也可以在redis之类的地方放20个库存key。

总之，就是把你的1000件库存给他拆开，每个库存段是50件库存，比如stock_01对应50件库存，stock_02对应50件库存。

接着，每秒1000个请求过来了，好！此时其实可以是自己写一个简单的随机算法，每个请求都是随机在20个分段库存里，选择一个进行加锁。

这样就好了，同时可以有最多20个下单请求一起执行，每个下单请求锁了一个库存分段，然后在业务逻辑里面，就对数据库或者是Redis中的那个分段库存进行操作即可，包括查库存 -> 判断库存是否充足 -> 扣减库存。

这相当于什么呢？相当于一个20毫秒，可以并发处理掉20个下单请求，那么1秒，也就可以依次处理掉20 * 50  = 1000个对iphone的下单请求了。

就是如果某个下单请求，咔嚓加锁，然后发现这个分段库存里的库存不足了,这时你得自动释放锁，然后立马换下一个分段库存，再次尝试加锁后尝试处理。