并发减库存，怎么保证不超卖？

作者：废物大师兄
来源：www.cnblogs.com/cjsblog/p/9135118.html

秒杀的场景有很多，比如：抢购、抢票、抢红包等等。总之，就是在极短时间内有大量的请求。

我们都知道，这种系统设计的大方向就是限流，即通过层层过滤，最终只让相对较少的请求进入到核心业务处理层。

这里不谈秒杀设计，不谈使用队列等使请求串行化，就谈下怎么用锁来保证数据正确，就是已经到减库存那一步了，在这一步中如果保证不超卖。

用队列的话，可以是Java自动的队列，也可以用Redis的LPUSH RPOP

重点是扣减库存

我理解，主要的方式是加锁。

加锁有两个层面：一个是程序层面，另一个是数据库层面。

分布式锁

这种场景下应该很少有人用Java自带的锁（比如：synchronized、Lock）吧，因为它们只在同一个JVM内有效，如果你的应用部署了多台的话，应该用分布式锁。

其实，这里加分布式锁就是将多线程请求转成单线程请求，因为每次只有一个线程获得锁并执行，其余都被阻塞了。

这里有一点需要注意，就是当你应用了事务的话可能会存在问题，请看下面的代码

可能有人会这样写，第一眼看起来挺好的，没问题啊，但仔细实践证明是由问题的。

我们知道，mysql默认的事务隔离级别是REPEATABLE-READ

在这种隔离级别下，同一个事务中多次读取，返回的数据是一样的

同时，Spring声明式事务默认的传播特性REQUIRED

Spring声明式事务是Spring AOP最好的例子，Spring是通过AOP代理的方式来实现事务的，也就是说在调用reduceStock()方法的之前就已经开启了事务。另外，关注公众号互联网架构师，在后台回复：2T，可以获取我整理的 Spring 系列面试题和答案，非常齐全。

那么，在并发情况下可能会存在这样的情况，假设线程T1和T2都执行到这里，于是它们都开启了事务S1和S2，T1先执行，T2后执行，

由于T2执行的时候事务已经创建了，根据隔离级别，这个时候事务S2读取不到S1已提交的数据，于是就会出现T1和T2读取到的值是一样的，即T2读取的是T1更新前的库存数据。

关于这一点，大家可以自己写个代码测试一下，下面是一段参考：

鉴于这种情况呢，可以将库存放到Redis中，我们直接读写Redis，这样可以避免受数据库事务的影响，当然这也会带来新的问题，不再讨论。另外，关注公众号互联网架构师，在后台回复：2T，可以获取我整理的 Redis 系列面试题和答案，非常齐全。

数据库乐观锁

CAS（compare and swap）比较并交换

在Java中，一个线程想修改某个变量的值，那么第一步是将变量的值从主内存中读取到自己工作内存中，然后修改，最后写回主内存。

这个过程可以归结为：读取——修改——写入，在写回内存的时候可能当前内存中那个值已经发生了变化，这个时候如果继续写则会覆盖别人的数据，只有当内存中的那个值和它修改之前读到的那个值一样，才可以写入。

这个跟数据库是一样的。

Java中通过Unsafe中compareAndSwapObject这样的方法类实现的，它直接调用CPU指令。

数据库中也有CAS，乐观锁就是一种CAS。

经典的乐观锁实现：

数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。

当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。

更新的时候带上版本号，只有当前版本号与更新之前查询时的版本一致，才会更新

ABA问题

这里顺便多提一句，CAS中的ABA问题

假设，原先的值是A，线程-1读取到的值是A，想把它改成D，但是在此期间，有可能其他线程已经多次修改过这个值，只不过最后当线程-1准备将A改成D的时候，它发现恰好还是A，以为没有人改过，其实这时候的A已经不是原来的A了。

也就是说，尽管修改之前做了比较，当然，仍然会出现如下情况：

产生原因

ABA问题导致的原因，是CAS过程中只简单进行了“值”的校验，有些情况下，“值”虽然相同，却已经不是原来的数据了。

优化方向

CAS不能只比对“值”，还必须确保的是原来的数据，才能修改成功。

常见实践

“版本号”的比对，一个数据一个版本，版本变化，即使值相同，也不应该修改成功。

不仅要关注值，还要关注是不是原来的对象

基于“值”的CAS乐观锁，可能导致ABA问题。CAS乐观锁，必须保证修改时的“此数据”就是“彼数据”，应该由“值”比对，优化为“版本号”比对。

参考：

https://www.sohu.com/a/150900817_178889
https://blog.csdn.net/zhjunjun93/article/details/78560700
https://blog.csdn.net/rexct392358928/article/details/52230737