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个下单请求一起执行。 如果某个下单请求，对一个分段加锁后，然后发现这个分段库存里的库存不足了，这时需要自动释放锁，然后立马换下一个分段库存，再次尝试加锁后尝试处理。这个过程一定要实现。
