浅谈并发扣库存

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

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

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

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

重点是扣减库存

我理解，主要的方式是加锁。加锁有两个层面：一个是程序层面（分布式锁），另一个是数据库层面（乐观锁）

1.分布式锁

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

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

将库存放到Redis中，我们直接读写Redis，这样可以避免受数据库事务的影响

2.乐观锁

在Java中，一个线程想修改某个变量的值，那么第一步是将变量的值从主内存中读取到自己工作内存中，然后修改，最后写回主内存。这个过程可以归结为：读取——修改——写入，在写回内存的时候可能当前内存中那个值已经发生了变化，这个时候如果继续写则会覆盖别人的数据，只有当内存中的那个值和它修改之前读到的那个值一样，才可以写入。这个跟数据库是一样的。Java中通过Unsafe中compareAndSwapObject这样的方法类实现的

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

经典的乐观锁实现：

数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。

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

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

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

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

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

refer:http://www.cnblogs.com/cjsblog/archive/2018/06/04/9135118.html