秒杀业务中的库存扣减为什么不加分布式锁？
前言
说到秒杀业务的库存扣减，就还是得先确认我们的扣减基本方案。
秒杀场景的库存扣减方案
一般的做法是，先在Redis中做扣减，然后发送一个MQ消息，消费者在接到消息之后做数据库中库存的真正扣减及业务逻辑操作。
如何解决数据一致性问题：
Redis中库存成功扣减了，但是后续发送MQ消息失败，或者后面的消费过程中消息丢了或者失败了等情况。
就会导致Redis中的库存被扣减了，但是数据库库存没扣减，业务的实际操作没发生。这时候的结果就是Redis中发生了多扣，那么带来的业务问题就是少卖。
对账机制：
想要解决这类数据不一致的情况，就需要引入一些对账的机制，做一些准实时的核对，处理这种数据不一致的情况。
常见的对账方案有，用zset在redis中添加流水记录，然后定时拉一段时间内的所有记录，和数据库比对，发现不一致，则进行补偿处理。
一般在成熟的电商公司中，不管前面的方案做的多么完善，这个核对系统都是必不可少的。及时的核对出超卖、少卖等问题。
库存扣减为什么不用分布式锁
实现秒杀的库存扣减，最重要的是两个点：
- 抗更高的并发。
- 避免超卖
尤其重要的就是这个防止超卖，这也是我们加锁的目的。
用lua脚本的优势： - lua脚本具有原子性：可以直接用利用他的原子性特性，在一个脚本中实现库存的检查、扣减等动作，避免超卖！
- 效率高：所有操作可以在一次脚本执行中完成，减少了网络传输时间和通信次数。
- 更加简洁，易于维护：所有操作可以在一次脚本执行中完成并且使得应用层的代码。
用分布式锁的缺点：
如果用了 tryLock，不考虑 waitTime的合理性情况下，和 lua 脚本的执行也差不多，就是排队执行。
- 效率低、增加系统复杂性：在不使用 lua 脚本的情况下，每次库存扣减操作都需要多次与 Redis 服务器通信（例如，加锁、读取库存、扣减库存、释放锁等）。这不仅增加了网络延时，还增加了系统的复杂性。
- 难管理：分布式锁需要细致的管理，包括锁的设置、维护锁的存活时间、处理死锁问题等。如果锁没有正确管理，可能会导致死锁或者锁失效，进而影响系统的稳定性和数据一致性。
总结
本片文章介绍了秒杀业务下的库存扣减方案，以及扣减的具体方案，解释了在扣减时为什么不用分布式锁，而用LUA脚本进行扣减的原因。希望这篇文章能够帮到你。感谢各位老铁一键三连。
ps: 买服务器返点；收徒中；面试全集在线文档,需要请私信。