秒杀的场景有很多，比如：抢购、抢票、抢红包等等。总之，就是在极短时间内有大量的请求。
我们都知道，这种系统设计的大方向就是限流，即通过层层过滤，最终只让相对较少的请求进入到核心业务处理层。
这里不谈秒杀设计，不谈使用队列等使请求串行化，就谈下怎么用锁来保证数据正确，就是已经到减库存那一步了，在这一步中如果保证不超卖。
用队列的话，可以是Java自动的队列，也可以用Redis的LPUSH RPOP
重点是扣减库存
我理解，主要的方式是加锁。加锁有两个层面：一个是程序层面，另一个是数据库层面。
分布式锁
这种场景下应该很少有人用Java自带的锁（比如：synchronized、Lock）吧，因为它们只在同一个JVM内有效，如果你的应用部署了多台的话，应该用分布式锁。
关于Redis分布式锁，可以阅读这篇文章：Spring Boot Redis 实现分布式锁
其实，这里加分布式锁就是将多线程请求转成单线程请求，因为每次只有一个线程获得锁并执行，其余都被阻塞了。
这里有一点需要注意，就是当你应用了事务的话可能会存在问题，请看下面的代码
可能有人会这样写，第一眼看起来挺好的，没问题啊，但仔细实践证明是由问题的。
我们知道，mysql默认的事务隔离级别是REPEATABLE-READ
关于事务隔离级别这块儿，可在公众号Java技术栈搜索阅读。
在这种隔离级别下，同一个事务中多次读取，返回的数据是一样的
同时，Spring声明式事务默认的传播特性REQUIRED
Spring声明式事务是Spring AOP最好的例子，Spring是通过AOP代理的方式来实现事务的，也就是说在调用reduceStock()方法的之前就已经开启了事务。
那么，在并发情况下可能会存在这样的情况，假设线程T1和T2都执行到这里，于是它们都开启了事务S1和S2，T1先执行，T2后执行，
由于T2执行的时候事务已经创建了，根据隔离级别，这个时候事务S2读取不到S1已提交的数据，于是就会出现T1和T2读取到的值是一样的，即T2读取的是T1更新前的库存数据。
关于这一点，大家可以自己写个代码测试一下，下面是一段参考：
鉴于这种情况呢，可以将库存放到Redis中，我们直接读写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乐观锁，必须保证修改时的“此数据”就是“彼数据”，应该由“值”比对，优化为“版本号”比对。
