秒杀超卖相关

https://mp.weixin.qq.com/s/bOmNpz9D59AcyHhY11WCUQ
一般购买商品流程：
请求下单、查询库存、校验库存、扣库存、创建订单、支付。

超卖描述：
如果并发秒杀商品，肯定会出现超卖的情况。
因为查询库存、校验库存、扣库存不是原子性的。

方案一： 乐观锁更新
为商品库存加版本字段，更新库存的时候判断版本是否和查询时一致，不一致表示库存被更新过，则更新失败，一致表示未被更新过，更新成功。

update stock sale = sale + 1, version = version + 1, WHERE 
id = #{id,jdbcType=INTEGER} AND version = #{version,jdbcType=INTEGER}

一般不会用这种方式，因为几乎所有的请求都走到了DB。

方案二： 乐观锁更新 + 限流
分析一下，假如库存是10，并发进来了1000个请求，其实99%的请求是无效的，应该不需要走到DB的，所以可以在入库处限流，只允许100个请求进入，将并发请求控制在可控范围，快速失败来保护系统。

方案三： 乐观锁更新 + 限流 + 缓存
每次请求查询库存的 SQL，主要是为了在每次下单之前判断是否还有库存。
这种数据我们完全可以放在内存中，效率比在数据库要高很多。
可以将库存数和售卖数保存到缓存，直接读取缓存判断库存是否充足。
只有在乐观锁更新库存成功后，讲库存数同步到缓存。

总结：
尽量将请求拦截在上游。
最大程度的减少请求落到 DB。
多利用缓存。
同步操作异步化。
尽早失败，保护应用。

库存超卖问题是有很多种技术解决方案的，比如： 悲观锁，分布式锁，乐观锁，队列串行化，Redis原子操作。
https://mp.weixin.qq.com/s?__biz=MzU0OTk3ODQ3Ng==&mid=2247483926&idx=1&sn=2a796ef514dea15790e45d79d233833e&chksm=fba6ea15ccd1630387b8738a00a8c1dc6ae0c535305ec4d6e3c76d64eff48bf1d47ae0eaea07&scene=21#wechat_redirect
每秒上千订单场景下的分布式锁高并发优化：
用分布式锁解决超卖问题？
分布式锁一旦加了之后，对同一个商品的下单请求，会导致所有客户端都必须对同一个商品的库存锁key进行加锁。这样会导致对同一个商品的下单请求，就必须串行化，一个接一个的处理。这样会导致吞吐量极低。

优化方案一： 分段加锁
ConcurrentHashMap 就是利用了分段加锁来解决并发读写性能问题的。
可以将库存数拆一下，比如库存10，拆成5个库存段，将5个库存段放到Redis，每个库存段是2个。
接着，每秒1000个请求过来了，好！此时其实可以是自己写一个简单的随机算法，每个请求都是随机在5个分段库存里，选择一个进行加锁。
这样同时可以有最多5个下单请求一起执行。
如果某个下单请求，对一个分段加锁后，然后发现这个分段库存里的库存不足了，这时需要自动释放锁，然后立马换下一个分段库存，再次尝试加锁后尝试处理。这个过程一定要实现。