一:抢订单环节带来的问题
- 高并发:大量用户同一时间抢购,网站瞬时访问量剧增,导致服务器压力大 。
- 超卖问题:成功下订单买到商品的人数,超过数据库最大库存数量。
二:出现高并发和超卖的原因?
- 1:首先MySQL自身对于高并发的处理性能就会出现问题,一般来说,MySQL的处理性能会随着并发thread上升而上升,但是到了一定的并发度之后会出现明显的拐点,之后一路下降,最终甚至会比单thread的性能还要差。
- 2:其次,超卖的根结在于减库存操作是一个事务操作,需要先select,然后insert,最后update -1。最后这个-1操作是不能出现负数的,但是当多用户在有库存的情况下
并发操作
,出现负数这是无法避免的。 - 3:最后,当减库存和高并发碰到一起的时候,由于操作的库存数目在同一行,就会出现争抢InnoDB行锁的问题,导致出现互相等待甚至死锁,从而大大降低MySQL的处理性能,最终导致前端页面出现超时异常。
三:解决方案:
3.1:数据迁移:
答:将存库从MySQL前移到Redis中,所有的写操作放到内存型数据库中。
由于Redis中[默认情况下]不存在锁,故不会出现互相等待,并且由于Redis的写性能和读性能都远高于MySQL,这就解决了高并发下的性能问题。然后通过队列等异步手段,将变化的数据异步写入到DB中。
优点:解决了性能问题。
缺点:没有解决超卖问题,同时由于异步写入DB,存在某一时刻DB和Redis中数据不一致的风险。
3.2:队列:
答:将所有写DB操作在单队列中排队,完全串行处理。当达到库存阈值的时候就不再消费队列,并关闭购买功能。这就解决了超卖问题。
优点:解决超卖问题,略微提升性能。
缺点:性能受限于队列处理机处理性能和DB的写入性能中最短的那个,另外多商品同时抢购的时候需要准备多条队列。
3.3:Mysql二段式提交+redis原子自增:
答:mysql的二段式提交将提交操作变成两段式,先申请后确认。
然后利用Redis的原子自增操作,同时利用Redis的事务特性来发号[watch 乐观锁],保证拿到小于等于库存阈值的号的人都可以成功提交订单。然后数据异步更新到DB中。
优点:解决超卖问题,库存读写都在内存中,故同时解决性能问题。
缺点:由于异步写入DB,可能存在数据不一致。另可能存在少买,也就是如果拿到号的人不真正下订单,可能库存减为0,但是订单数并没有达到库存阈值
3.4:服务器解决性能瓶颈问题
1.排队:
可以使用消息队列,将同步请求转化成异步请求,中间通过一个消息队列在一端[队列入口]承接瞬时的流量峰值,在另一端[队列出口]平滑的将消息推送出去
2.设置关卡:
在活动入口的地方设置关卡游戏或者问题环节,削弱峰值
3.分层过滤:
秒杀请求先经过CDN ==> 前端系统 ==> 后端系统 过滤掉无效请求