如何解决秒杀的性能问题和超卖的讨论 - billy鹏
最近业务试水电商,接了一个秒杀的活。之前经常看到淘宝的同行们讨论秒杀,讨论电商,这次终于轮到我们自己理论结合实际一次了。
ps:进入正文前先说一点个人感受,之前看淘宝的ppt感觉都懂了,等到自己出解决方案的时候发现还是有很多想不到的地方其实都没懂,再次验证了“细节是魔鬼”的理论。并且一个人的能力有限,只有大家一起讨论才能想的更周全,更细致。好了,闲话少说,下面进入正文。
一、秒杀带来了什么?
秒杀或抢购活动一般会经过【预约】【抢订单】【支付】这3个大环节,而其中【抢订单】这个环节是最考验业务提供方的抗压能力的。
抢订单环节一般会带来2个问题:
1、高并发
比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验。
2、超卖
任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难题。
二、如何解决?
首先,产品解决方案我们就不予讨论了。我们只讨论技术解决方案
1、前端
面对高并发的抢购活动,前端常用的三板斧是【扩容】【静态化】【限流】
A:扩容
加机器,这是最简单的方法,通过增加前端池的整体承载量来抗峰值。
B:静态化
将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素。通过CDN来抗峰值。
C:限流
一般都会采用IP级别的限流,即针对某一个IP,限制单位时间内发起请求数量。
或者活动入口的时候增加游戏或者问题环节进行消峰操作。
D:有损服务
最后一招,在接近前端池承载能力的水位上限的时候,随机拒绝部分请求来保护活动整体的可用性。
2、后端
那么后端的数据库在高并发和超卖下会遇到什么问题呢?主要会有如下3个问题:(主要讨论写的问题,读的问题通过增加cache可以很容易的解决)
I: 首先MySQL自身对于高并发的处理性能就会出现问题,一般来说,MySQL的处理性能会随着并发thread上升而上升,但是到了一定的并发度之后会出现明显的拐点,之后一路下降,最终甚至会比单thread的性能还要差。
II: 其次,超卖的根结在于减库存操作是一个事务操作,需要先select,然后insert,最后update -1。最后这个-1操作是不能出现负数的,但是当多用户在有库存的情况下并发操作,出现负数这是无法避免的。
III:最后,当减库存和高并发碰到一起的时候,由于操作的库存数目在同一行,就会出现争抢InnoDB行锁的问题,导致出现互相等待甚至死锁,从而大大降低MySQL的处理性能,最终导致前端页面出现超时异常。
针对上述问题,如何解决呢? 我们先看眼淘宝的高大上解决方案:
I: 关闭死锁检测,提高并发处理性能。
II:修改源代码,将排队提到进入引擎层前,降低引擎层面的并发度。
III:组提交,降低server和引擎的交互次数,降低IO消耗。
以上内容可以参考丁奇在DTCC2013上分享的 《秒杀场景下MySQL的低效》 一文。在文中所有优化都使用后,TPS在高并发下,从原始的150飙升到8.5w,提升近566倍,非常吓人!!!
不过结合我们的实际,改源码这种高大上的解决方案显然有那么一点不切实际。于是小伙伴们需要讨论出一种适合我们实际情况的解决方案。以下就是我们讨论的解决方案:
首先设定一个前提,为了防止超卖现象,所有减库存操作都需要进行一次减后检查,保证减完不能等于负数。(由于MySQL事务的特性,这种方法只能降低超卖的数量,但是不可能完全避免超卖)
update number set x=x-1 where (x -1 ) >= 0;
解决方案1:
将存库从MySQL前移到Redis中,所有的写操作放到内存中,由于Redis中不存在锁故不会出现互相等待,并且由于Redis的写性能和读性能都远高于MySQL,这就解决了高并发下的性能问题。然后通过队列等异步手段,将变化的数据异步写入到DB中。
优点:解决性能问题
缺点:没有解决超卖问题,同时由于异步写入DB,存在某一时刻DB和Redis中数据不一致的风险。
解决方案2:
引入队列,然后将所有写DB操作在单队列中排队,完全串行处理。当达到库存阀值的时候就不在消费队列,并关闭购买功能。这就解决了超卖问题。
优点:解决超卖问题,略微提升性能。
缺点:性能受限于队列处理机处理性能和DB的写入性能中最短的那个,另外多商品同时抢购的时候需要准备多条队列。
解决方案3:
将写操作前移到MC中,同时利用MC的轻量级的锁机制CAS来实现减库存操作。
优点:读写在内存中,操作性能快,引入轻量级锁之后可以保证同一时刻只有一个写入成功,解决减库存问题。
缺点:没有实测,基于CAS的特性不知道高并发下是否会出现大量更新失败?不过加锁之后肯定对并发性能会有影响。
解决方案4:
将提交操作变成两段式,先申请后确认。然后利用Redis的原子自增操作(相比较MySQL的自增来说没有空洞),同时利用Redis的事务特性来发号,保证拿到小于等于库存阀值的号的人都可以成功提交订单。然后数据异步更新到DB中。
优点:解决超卖问题,库存读写都在内存中,故同时解决性能问题。
缺点:由于异步写入DB,可能存在数据不一致。另可能存在少买,也就是如果拿到号的人不真正下订单,可能库存减为0,但是订单数并没有达到库存阀值。
三、总结
1、前端三板斧【扩容】【限流】【静态化】
2、后端两条路【内存】+【排队】
四、非技术感想
1、团队的力量是无穷的,各种各样的解决方案(先不谈可行性)都是在小伙伴们七嘴八舌中讨论出来的。我们需要让所有人都发出自己的声音,不要着急去否定。
2、优化需要从整体层面去思考,不要只纠结于自己负责的部分,如果只盯着一个点思考,最后很可能就走进死胡同中了。
3、有很多东西以为读过了就懂了,其实不然。依然还是需要实践,否则别人的知识永远不可能变成自己的。
4、多思考为什么,会发生什么,不要想当然。只有这样才能深入进去,而不是留在表面。
ps:以上仅仅是我们讨论的一些方案设想,欢迎大家一起讨论各种可行方案。
其它相关文章:
相关推荐
高性能电商秒杀解决方案 秒杀的特点 • 大量用户在秒杀时间点发起购买请求,造成网站流量瞬间激增; • 秒杀的商品一般库存较少,只有少数用户能够购买,要控制好库存,防止超卖; • 整个系统关键在于支撑短时间内...
在众多抢购活动中,在有限的商品数量的...还有就是抢购时会出现大量用户的访问,如何提高用户体验效果也是一个问题,也就是要解决秒杀系统的性能问题。本文主要介绍基于redis 实现商品秒杀功能。先来跟大家讲下大概思路
高并发环境下是很容易发生库存的情况,这个demo演示了使用RabbitMQ解决高并发环境下超卖问题。
1.C# .Net Core 极光推送代码 2.Redis的类库 3.Redis中的String类型及使用Redis解决订单秒杀超卖问题
本系列将和大家分享Redis分布式缓存,本章主要简单介绍下Redis中的String类型,以及如何使用Redis解决订单秒杀超卖问题。 Redis中5种数据结构之String类型:key-value的缓存,支持过期,value不超过512M。 Redis是...
主要这个秒杀方案分为六部分: 1、分布式会话: 2、功能开发:商品列表、商品详情、秒杀、订单详情 ...4、页面优化(商品会不会出现超卖、性能有没有提高等问题) 5、服务优化(解决暴露出来的问题,超卖) 6、安全优化
这个Demo演示了使用redis乐观锁机制解决高并发环境下出现连接超时与超卖(库存出现负数)情况的解决办法。
使用Springboot+redis实现秒杀,解决商品的超卖已经用户重复购买问题
利用redis的高性能和事务特性来解决线上优惠券被超库存抢购的问题,下面我给出我临时解决这个问题的第一版的伪代码,去掉了一些细节: /** * 抢优惠券(秒杀) * @param int $couponId 商品ID * @param
微服务 Spring Boot 整合Redis 秒杀 ,全局唯一ID,乐观锁解决库存超卖,Jmeter 测试 每秒千万级并发
超卖和分布式锁解决方案.docx
秒杀需要解决的问题: 1) 库存超卖 解决方案: 1) 悲观锁:synchronize 、 Lock 2) 乐观锁:数据库乐观锁版本号控制 2) 高并发情况下系统压力以及用户体验 解决方案: redis 本教程采用:redis中list类型达到令牌...
一个微服务 Spring Boot 整合Redis 秒杀 ,全局唯一ID,乐观锁解决库存超卖,Jmeter 测试 每秒千万级并发 项目
上一篇文章聊了一下使用Redis事务来解决高并发商品超卖问题,今天我们来聊一下使用Redis链表来解决高并发商品超卖问题。 实现原理 使用redis链表来做,因为pop操作是原子的,即使有很多用户同时到达,也是依次执行,...
适用于高并发场景下商品秒杀,包含内容商品超卖问题、接口访问限流问题、Redis限时抢购、隐藏秒杀接口、单用户限制访问频率!为什么使用秒杀】 严格防止超卖 库存100件 你卖了120件 等着辞职吧! 防止黑客 假如我们...
这是一个关于如何设计商城秒杀系统的思想。完美的解决了超卖问题和数据存盘问题。有需要的朋友可以看一下。
全能RSI超买超卖交易策略,RSI是确认趋势的强度是涨跌点数之和比率制作的一种技术曲线,是反映出市场在一定时期内的景气程度,当RSI高于50水平并开始下跌,表明上涨趋势正在减弱,当低于50并开始上涨,表明下跌趋势...
在高并发电商场景下,商品超卖(即销售量超出库存)是常见问题,主要由并发扣减库存导致。常规做法是在扣减库存前检查库存充足性,...总的来说,解决商品超卖问题需要综合运用多种技术和策略,以适应复杂的高并发场景。
开发环境:IDEA,Tomcat,MySQL,Redis 项目构建:Maven ...出现超卖/少卖 三、难点分析 MySQL:事务 + 行级锁 多用户秒杀 ——> Update库存数量 四、功能模块 秒杀接口暴露(Exposer,封装的