优惠卷业务超卖问题解决方案

问题背景

在在线教育业务中，因为功能的扩展刺激消费通常会有一个优惠卷的功能，当时这些优惠卷通常是限量的需要学员自助领取，在一些特定场景下会出现学员领取卷的总数量大于运营设置的卷的总数量，这就是超卖问题的现象，或许在这个创建下叫做“超领”可能更合适些。

产生原因

假设当前运营设置了10张优惠卷，前面9已经被抢完了，还是最后一张，但是此时有三个学员在相同时间下都做了领卷的操作，最终导致三个学员都领到卷了，导致领取总量大于发放总量。

解决方案

1.保证数据的原子性。添加发放总量 大于 以发放量的条件，保证多个在事务操作下数据的总量不会发生改变。

优点：代码改动量下，并且效果比较好，不会出现ABA的问题。（目前我们公司就是使用这个方案）

缺点：

• 事务为了保证原子性，会在对这个优惠卷数据上行锁。
• 在没有设置索引的时候可能会做全量扫描，效率上会变低。因此我们需要设置对应的有效索引防止走全表。
• 在极端的情况下会更新失败，需要设置重试机制。当有多跟线程同时操作的时候，通过更新时回去行级锁来控制执行顺序，因为某些原因导致获取获取锁超时，最总导致更新失败。

2.悲观锁。通过synchronized对优惠卷id进行上锁，每次只有一个保证请求是串行的，执行速度比较慢，当时确实是最可靠的。

3.乐观锁。优点：保证了在请求的并行执行，在执行效率上是很高。

缺点：在请求大量的时候虽然都可以执行，但是最终只会有一个执行超过，在完成率上是比较低的。实现上通过版本号进行控制。在实现上是三者中最繁琐的。我们没有单独定义本号字段来做的，我们是使用更新时间做版本号的来实现的。

在极端情况下乐观锁会出现无法感知的超卖情况。但是对我们目前的业务场景不会造成影响。

极端的场景 （ABA）：对总数不影响，导致可能会导致业务逻辑错误，保证数据的原子性就会存在这个问题。

时间线： 1. 线程A读到 version = 1, issued_count = 99 2. 线程B更新：issued_count = 100, version = 2 3. 线程C（退款）更新：issued_count = 99, version = 3 4. 线程A执行更新，version匹配成功！错误地认为数据没变