秒杀业务中的库存扣减为什么不加分布式锁？

前言

说到秒杀业务的库存扣减，就还是得先确认我们的扣减基本方案。

秒杀场景的库存扣减方案

一般的做法是，先在Redis中做扣减，然后发送一个MQ消息，消费者在接到消息之后做数据库中库存的真正扣减及业务逻辑操作。

如何解决数据一致性问题：

Redis中库存成功扣减了，但是后续发送MQ消息失败，或者后面的消费过程中消息丢了或者失败了等情况。
就会导致Redis中的库存被扣减了，但是数据库库存没扣减，业务的实际操作没发生。这时候的结果就是Redis中发生了多扣，那么带来的业务问题就是少卖。

对账机制：
想要解决这类数据不一致的情况，就需要引入一些对账的机制，做一些准实时的核对，处理这种数据不一致的情况。

常见的对账方案有，用zset在redis中添加流水记录，然后定时拉一段时间内的所有记录，和数据库比对，发现不一致，则进行补偿处理。

一般在成熟的电商公司中，不管前面的方案做的多么完善，这个核对系统都是必不可少的。及时的核对出超卖、少卖等问题。

库存扣减为什么不用分布式锁

实现秒杀的库存扣减，最重要的是两个点：

1. 抗更高的并发。
2. 避免超卖
   尤其重要的就是这个防止超卖，这也是我们加锁的目的。
   用lua脚本的优势：
3. lua脚本具有原子性：可以直接用利用他的原子性特性，在一个脚本中实现库存的检查、扣减等动作，避免超卖！
4. 效率高：所有操作可以在一次脚本执行中完成，减少了网络传输时间和通信次数。
5. 更加简洁，易于维护：所有操作可以在一次脚本执行中完成并且使得应用层的代码。

用分布式锁的缺点：
如果用了 tryLock，不