17.抢购(秒杀)业务的技术要点
原文地址:https://www.cnblogs.com/wangtao_20/p/7057861.html
抢购业务数据库需要考虑的点如下:
一、超卖现象
场景如下:
库存数是5。现在3个用户来购买,a用户购买2个,b用户购买3个,c用户购买1个。合起来就是准备购买6个。
如果三个用户是同时并发购买,会出现怎样的情况呢?
每个用户进行减库存的时候,语句类似于:
1
|
update goods set amount=amount-购买数量 where goods_id=xxx。 |
mysql会锁定这一行数据(使用innodb存储引擎),数据库加的是排他锁。根据排他锁的特点:其他线程不能读、不能写此行数据。
排他锁情况下,那么其他用户就是等待状态了。
1、A用户执行update的时候,锁定库存数据。update执行完毕后,减去了2个后,mysql自动释放锁。
2、b用户执行,减去了3个。此时,已经卖掉5个库存了。库存数为0了。
3、但是c用户接着执行,Update goods set amount=amount-1 where goods_id=xxx
结果库存数量变成-1了。
思考:把库存数量字段的类型,设计成正数类型,不允许出现负数,会怎么样呢?
测验结果:数据库会直接报错。通不过。
解决办法:只有库存数量,大于或等于购买数量的时候,才能去减库存。其他情况,提示信息,库存不足。
sql语句如下:
update goods set amount=amount-购买数量 where goods_id=xxx AND amount>=购买数量
这样,轮到c执行的时候,由于使用了amount>=购买数量做限制条件,update语句返回的受影响的行数是0,意味着执行失败了。直接提示,库存不足。
二、并发抢购造成的速度慢问题
1、实现方式对比:悲观锁与乐观锁
第一种问题中描述的超卖现象,其实是并发抢购时出现的情况。用到的是数据库内带的加排他锁方式,阻止了其他线程读取、访问数据,这要等待操作完毕后其他线程才能操作,这种方式是悲观锁方式。这样会等待下去。
使用数据库的悲观锁,是避免了数据并发更新,但是,加锁毕竟是很耗服务器资源的,用户要等待下去。所以并不能达到好的性能和高并发。
业界使用乐观锁的办法来解决:使用数据库的乐观锁是通用解决办法。通用锁实现了版本控制。不会进行排斥掉。减少资源的消耗。
乐观锁是相对悲观锁而言的,使用的是更加宽松的锁定方式。
乐观锁,通俗说就是:修改数据的时候,不给数据加锁。
既然不加锁,其他线程也是可以访问、修改数据。但是,修改的时候会获取一个版本号,只有版本号符合了,才算更新成功。
不成功的,都算抢购失败。
2、乐观锁的具体实现方式
乐观锁的机制与代码版本库svn很相似,这种方式,叫做多版本记录方式。
如果在我提交代码之前用本地代码的版本号与服务器做对比,如果本地版本号小于服务器上最新版本号,则提交失败,产生冲突代码,让用户决定选择哪个版本继续使用。
逻辑描述:
if(之前读取到行的版本号+1=数据库此行现在的版本号+1){
//符合预期,数据库的数据没有给其他用户修改掉。可以直接写入数据了
}else{
//数据已经被修改了。所以当前的版本已经落后了。不能进行更新
}
例子:
给表goods加一个版本字段version,用来记录行数据值的版本号。
版本号version字段,设计成一个正整数,比如是时间戳。每次修改后,要将version字段的值加1: 1496916794、1496916795、1496916796、1496916797、1496916798.................
读数据的时候,顺便将版本号的值读取出来。update时,做版本号对比,如下:
1、先读取这个商品的信息,顺便将版本号读取出来
1
|
select amount,version from t_goods where goods_id=8899; |
2、更新数据
1
2
3
|
update goods set amount=amount-2,version=version+1 where goods_id=8899 and version=#{version} and amount>=2; |
sql解释:
#{version}是之前select读取到的版本号,填入进去,意思是只能修改这样的。
修改的时候,限制条件-必须版本号等于原来的版本号才能去修改。否则不能修改。更新成功的同时,版本号要加1。
优点:使用数据库的乐观锁是通用解决办法。通用锁实现了版本控制。线程之间同时操作,不加锁,线程不用等待了。减少了数据库资源的消耗。
缺点:会增加cpu的计算开销。不过值得这样做,由于没有加锁进行阻塞,用户不用等待结果,很快能等到执行结果了,用户体验更好。抢购的并发数其实提高了。
三、减库存和下单保持在一个事务内
如果不在一个事务内,可能出现两种现象:
1、订单入库失败、减库存成功。发现订单入库失败,减库存就不要继续进行下去了。
2、订单入库成功、减库存失败。实际下了20个订单,库存却没有减。数据不一致了。
四、虚拟库存和真实库存两套方案
考虑几种情况:
1、有些人下单完后,最终并不会去付款。如果一下单就马上减库存,很多人下单,最终并不会去付款,可能导致库存数最后为0,别的用户无法下单了。而实际中仓库中却有库存在,这样库存数据是不准确的。
2、什么时候减库存? 是下单完成减库存、还是付款完后减库存呢?
付款后,才减库存,可能出现的现象:用户下完单,接着去付款,结果库存不够了。这样用户体验很不好。
下完单就减库存,能够保证用户下单只要付款,就一定能买到这个商品。用户体验较好。
针对一些人下单后,不付款,占着库存资源,其他人无法下单。这个问题好解决,给付款设置一个有效期限,比如30分钟。超过这个时间,库存就释放掉了。
具体技术实现办法:下单后,马上减去库存。另外设置一个定时脚本,扫描超过30分未支付的订单,把订单中的商品数量返回到库存中去。
为什么使用虚拟库存和真实库存两套方案?
假设库存数是50,a订单购买了5个件商品,支付完毕,库存数减去5,库存数变成了45件。由于还没有发货,实际库存中还有50件商品。这样会出现混淆了。
使用两套库存记录方案是有必要的!
- 下单-操作虚拟库存数
- 商品发货出库-操作真实库存数
真实库存数,记录下仓库中这件商品真有多少件。真实库存,其实非常方便内部人员查看,它只有商品出库,这个库存才减。
虚拟库存,用来应对商品购买的。表明,还有多少数量可以给用户去购买。并不表示仓库中的库存数。
五、频繁读库存的压力
因为,每次点击,都要读取库存,判断:有没有库存。如果读库存走的是数据库判断,很多人来抢购的情况下,数据库的压力会很大。
假设是1万个用户同时访问抢购页面。数据库接受的访问次数是1万个并发。
用户还要进行刷新页面操作,由于每次刷新都会走数据库判断库存。数量会更大。数据库的压力就更大了。
所以最好是,把库存总数,缓存在redis中去。
内存中缓存的库存数量,只用来做读判断。这样压力扛住了。而更改数据库的库存总数了,程序马上要把库存总数,同步到缓存中去。
系统抗压力问题
一、如何限流
二、如何防止恶意刷数据。
防止的就是写代码去频繁请求,为了识别是机器还是人工。加友好一点的验证码。