并发减库存

xiaoxiao2021-02-28  20

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

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

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

用队列的话,可以是Java自动的队列,也可以用Redis的LPUSH RPOP

重点是扣减库存

我理解,主要的方式是加锁。加锁有两个层面:一个是程序层面,另一个是数据库层面。

分布式锁

这种场景下应该很少有人用Java自带的锁(比如:synchronized、Lock)吧,因为它们只在同一个JVM内有效,如果你的应用部署了多台的话,应该用分布式锁。

关于Redis分布式锁,可以看我之前的一篇《基于Redis的分布式锁的简单实现》

其实,这里加分布式锁就是将多线程请求转成单线程请求,因为每次只有一个线程获得锁并执行,其余都被阻塞了。

这里有一点需要注意,就是当你应用了事务的话可能会存在问题,请看下面的代码

可能有人会这样写,第一眼看起来挺好的,没问题啊,但仔细实践证明是由问题的。

我们知道,mysql默认的事务隔离级别是REPEATABLE-READ

关于事务隔离级别这块儿,可参考《mysql事务隔离级别》

在这种隔离级别下,同一个事务中多次读取,返回的数据是一样的

同时,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乐观锁,必须保证修改时的“此数据”就是“彼数据”,应该由“值”比对,优化为“版本号”比对。

大家有兴趣可以加我一起探讨技术,微信:3885115
转载请注明原文地址: https://www.6miu.com/read-2149969.html

最新回复(0)