Java架构-每秒上千订单场景下的分布式锁高并发优化实践！

“上一篇文章我们聊了聊Redisson这个开源框架对Redis分布式锁的实现原理，如果有不了解的兄弟可以看一下：《拜托，面试请不要再问我Redis分布式锁实现原理》。

今天就给大家聊一个有意思的话题：每秒上千订单场景下，如何对分布式锁的并发能力进行优化？

背景引入

首先，我们一起来看看这个问题的背景？

前段时间有个朋友在外面面试，然后有一天找我聊说：有一个国内不错的电商公司，面试官给他出了一个场景题：

假如下单时，用分布式锁来防止库存超卖，但是是每秒上千订单的高并发场景，如何对分布式锁进行高并发优化来应对这个场景？

他说他当时没答上来，因为没做过没什么思路。其实我当时听到这个面试题心里也觉得有点意思，因为如果是我来面试候选人的话，应该会给的范围更大一些。

比如，让面试的同学聊一聊电商高并发秒杀场景下的库存超卖解决方案，各种方案的优缺点以及实践，进而聊到分布式锁这个话题。

因为库存超卖问题是有很多种技术解决方案的，比如悲观锁，分布式锁，乐观锁，队列串行化，Redis原子操作，等等吧。

但是既然那个面试官兄弟限定死了用分布式锁来解决库存超卖，我估计就是想问一个点：在高并发场景下如何优化分布式锁的并发性能。

我觉得，面试官提问的角度还是可以接受的，因为在实际落地生产的时候，分布式锁这个东西保证了数据的准确性，但是他天然并发能力有点弱。

刚好我之前在自己项目的其他场景下，确实是做过高并发场景下的分布式锁优化方案，因此正好是借着这个朋友的面试题，把分布式锁的高并发优化思路，给大家来聊一聊。

库存超卖现象是怎么产生的？

先来看看如果不用分布式锁，所谓的电商库存超卖是啥意思？大家看看下面的图：

这个图，其实很清晰了，假设订单系统部署两台机器上，不同的用户都要同时买10台iphone，分别发了一个请求给订单系统。

接着每个订单系统实例都去数据库里查了一下，当前iphone库存是12台。