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

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

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

用队列的话，可以是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值相等，则予以更新，否则认为是过期数据。

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