聊聊高并发下库存加减那些事儿

不定期福利发放哦

聊聊高并发下库存加减那些事儿

     一般在日常开发中经常会遇到打折促销，秒杀活动，就如拼多多最近的4999抢券买爱疯11促销活动，毕竟谁的钱也不是大风刮来的，有秒杀有促销必定带来大量用户，而这类活动往往支撑着公司重要营销策略，所以保证系统在高并发下不出异常非常关键，这其中棘手的便是如何在高并发下高效的处理库存数据。今天就来聊聊高并发下库存加减那些事儿。

首先我们要明确重要的一点是减库存是需要顺序的，而需要顺序就意味着不能有并发加减库存的操作，为了实现顺序，一般做法都是将多线程强行变为单线程实现同步操作或者所说的顺序，将多线程变为单线程方案普遍做法便是使用锁或者借助队列。另一方面由于大型互联网应用面向大量用户所以都是大型分布式加集群作为最基础的架构，而由于架构原因，往常所使用的lock或者Synchronized进程锁关键字失去了意义(只能锁住当前Web程序代码块，但无法锁住集群中其他Web程序)。此时我们便要借助分布式锁或者MQ组件来达到跨进程跨主机的单线程效果。

接下来我们以ABC下单减库为例说明分布式下的减库存场景

ABC同时发起库存减1的请求

服务器接收到三个减库存操作，利用分布式锁锁住了减库存的逻辑，每次只限一个请求操作.对A请求进行库存减1操作后，再对B进行操作，one by one 以此类推。

目前减库存操作运行很好，不会发生超卖情况，老板再也不担心程序员败家了。但是以上减库存的逻辑有个很大的问题便是由于强行将多线程请求变为单线程，不可避免的导致排队的发生，这样会发生什么情况呢？

越后进分布式锁或者队列的请求他需要的响应时间越久因为他的响应时间是前面所有请求的响应时间之和。当然有人会说增加配置或者在redis中减库存再利用rabbitmq将结果同步到数据库中，由于操作内存中的数据让减库存操作响应加快，这的确对单次的减库存有效，但是随着并发提高，单次减库存响应时间的优化必将遇到瓶颈。依然没有解决高并发下所有人必须强行排队导致的问题。那有没有那种又顺序执行又能相对的并行加减库存操作呢？

减库存必定是顺序排队的，这毋庸置疑，但是有没有办法可以加快这个排队呢，答案是有的！

只有将同步减库存逻辑变为异步才能从根本解决排队问题。但是有人会说这与库存操作的逻辑(同步顺序排队)冲突。

其实这里所说的异步是相对的，什么意思呢？

首先全局库存是必须顺序操作的，但是如果我们把库存分割成N块，每一块内部是顺序的，但是每一块彼此之间又是异步的。这样就很好的解决了库存顺序执行的逻辑又减轻了排队的影响。有人会问这里是如何减轻的呢？首先来给减库存算一笔响应时间的账：

假设每个减库存操作的响应时间优化到50毫秒，并发2000，按照常规做法加全局锁那第2000个人的响应时间便是前面1999个用户的响应时间加他自己的50毫秒之和为100秒。100秒的响应可能用户早就心里默默诅咒你了。而且这已经是非常理想化的单次响应时间了。如果有人说可以优化到2毫秒就不会超时了。。麻烦带上键盘去微博杠吧。。

如果使用第二种方案假设三个用户请求减库存操作，完全可以让三个请求进三个不同的锁去扣减各自的库存数，此时三人没有排队可以保证他们同时减库存，而又不影响库存总数的准确性，因为三个请求操作的是各自锁所维护的库存数。随着业务增长，库存总数的分割可以不断细分直到缩短响应时间到合理范围，而这个库存总数的分割很好的保证了不会遇到瓶颈。但是由于这种业务架构的设计，导致业务不得不变得复杂，可以看到我们在进入分布式锁之前有一个称为库存总数协调器的模块，这个模块是用来做什么的呢？

首先我们把库存分割成多块后解决的首要问题便是如何让请求均匀的依次进入每一个分布式锁中进而操作当前锁所负责的库存数。

库存协调器的逻辑完全看各位自己业务模型来决定，你可以用雪花算法均匀分布也可使用ip或者用户标识取余去覆盖到每一个锁，总之实现方式看业务情况来决定，当然了很大几率会出现有的库存块内的库存总数消耗完了但有的还剩余，所以库存协调器一定要考虑到这类情况及时将库存较多的库存块内的库存数分散给其他库存块，以达到多线程减库存的效果。

从示例图中可以看到引入了rabbitmq，他在当前整个业务架构中的作用主要是每一个分布式锁处理完当前库存块的库存后要将当前加减的数量丢给消息队列，由消费端慢慢消化这些操作到数据库。

其实解决高并发业务只要你遵循让一个变成多个的思路，很多都有解决办法等着你

提前预祝中华人民共和国成立70周年 国庆快乐。。