如何设计电商行业亿级用户秒杀系统

电商行业在近十几年中,经历过大大小小的促销活动和秒杀上百次,每次做秒杀瞬时访问量会翻数十倍,甚至数百倍。对系统架构是巨大的考验,期间也曾经历过系统宕机,甚至整体雪崩。那么我们怎么设计秒杀系统,才能保证秒杀系统的高性能和稳定性,同时还要保证日常业务不受影响呢?

先看看秒杀场景特点。秒杀开始前几分钟,大量用户开始进入秒杀商品详情页面,很多人开始频b A W ? ; ^繁刷新秒杀商品详情页,这时秒杀商品详情页访问量会猛增。秒杀开始,大量用户开始抢购,这时创建订单,扣库存压力会显著增大。实际上,秒杀场景基本都是秒杀参与人多,E % U E 4 ] e G秒杀成功的人却寥寥无几,经常是几十万人或者更多人抢几百个商品库存。

那么我们曾经是怎么设计秒杀系统的呢?主V Y * D j 7要涉及以下几个方面:

秒杀业务流程上的考虑:

由于参加秒杀的商品售] 7 t y卖价格非常低,基本都是“抢到即赚到”,I I [成功下单d u _ - V后却不付款的情况非常少。所以我们采用下单减库存的方案,下单时扣减库存,然后再进行支付。假如真有个别订单不付款怎么办?没关系,秒杀好活动最主要的目e l - I # x 6的是吸引流量,个V : 2 s V别订单不支付对秒杀活动本身影响不大。况且,没支付剩下的库存还可以做为普通商品继续售卖。不过要注意对机器人和自动脚本的防御,后面会详细介绍。

页面静态化:

“秒杀开始前几分钟,大量用户开始进入秒杀商品详情页面,很多人开始频繁刷新秒g J G { [ ? , [杀商品详情页,这时秒杀商品详情页访问量会猛增”。如果请求全部打到后端服务,那后端服务的压力会非常大(后端服务要处理业务逻辑,而且还要访问数据库,吞吐量比! U _ f U E ]较低)。

考虑到秒杀是运营+ E # 0 2 u n ^同学提前安排的活动,要秒杀哪些商品、商品价格等信息在秒杀活动开始前已经确定下来,所以我们可以把秒杀商品详情页做成u N B 4 U 7 . F o静态页面,把商品详情、商品价格等参数、评论评价W + i r 8 Q a } D等信息全部放在这个静态页面里,然后把这个静态页面上传到CDN上预热(CDN是内容分发网络,可以简单理解成互联网上的0 C ] W g ? 8 }巨大的缓存,用于存放静态页面、图片、视频等,可以显著提高访问速度),用CDN扛流D , b : M ` U 量,这样大量的商品详情页的访问请求就不用访问自己的网站(源站)。这样既可以提高访问速度,也没有给网站增加压力,同时也减少了网站带宽压力。

如何设计电商行业亿级用户秒杀系统

请求拦截:

前端页面,相关按钮点击后置灰,防止重复提交

网关(zuul,nginx)层,为了避免前端恶意请求,F Z p 6 K比如一些攻击脚本,在j _ [ j u R C网关层要对下Q b L o E |单等接口按userID限流,几秒钟只能访问一d 5 J -次。考虑到秒杀场景参I 2 . U k R A {与人多,秒杀成功的人极少,我们可以把绝大部分抢购下单请@ 6 e M d i K求在网关层直接拒掉,按秒杀失败处理。这样就极大减少了后端服务的压S ] i d 9 [ N力。

假设秒杀库存是200个,我们可以只放行200个请求到后端服务。要注意,为了尽量避免库存被机器人和自动脚本抢走,200个请求不能在秒杀开始瞬间同时放行,可以分段放行,比如秒杀开始后随机选取K k o m q k F100ms内的5个请求放行R ` , l 4 O -(这100ms内的其他请求直F q C n R O接拒掉: G / 8,按秒杀失败处理),之后每隔* 1 .100ms放行5个请求,4秒钟可以放行完200个请求。分段放行,除了限制了机器人和自动脚本,把请求分散在各个时间o S i $ l k段,还进一步缓解了后端服务的压力。

分段放行总时间不能太长,假如每100ms放行1个请求,放行完Z h p K d y所有200个请求需要20秒时间,这样用户就会明显感知到下单K w % f f早的人没秒杀成功,下单晚的人反而u q z 5 [ ; B秒杀成功了,用户= + p :体验# l {会变差。

另外,秒杀过程网关压力会比较大,网关可以做成集群,多节点分摊访问压力。

如何设计电商行业亿级用户秒杀系统

后端服务设计:

如果秒杀库存只有200,经过网关拦截,再加上采用F { . J N C B分段放行的方式,对于后端服务基本没什么压力了,日常的后端服务就完全可以支撑秒杀活动了。不用再做更复杂的Y u = e / 9 w p b设计。不过,假如秒杀库存有几万个,放行的下单请求就有几万个,为了用户体验放行总时间也不能太长,这时后端服务该怎么设计呢?
这时主要压力S i H v .就在数据库了,扣减库存压力,创建订单Y Z N R / Y s压力。

库存可以放到Reids缓存中,来提高扣减库存吞吐能力。对于热点商品的库存可以利用Redis分片存储。

创建订单可以走异步消息队列。后端服务接到下单请求,直接放进消息队列,监听服务取4 V { c ( C Z出消息后,先将订单信息写入Redis,每隔100ms或者积攒100条订单,批量写入数据库一次。前端页面下单后定时向后端拉取订单信息,获取到订单信息后跳转到支付页面。用这种批量异步写入数据库的方式大幅减少了数据库写入频次,从而明显降低了订单数据库写入压力。

如何设计电商行业亿级用户秒杀系统

隔离:

1,业务隔离。从业务上把秒杀和日常的售卖区分开来,把秒, / ; ^ C 4杀做为营销S ` ; c G ~ m动,要参与秒杀的商品需要提前报名参加活动,这样我们就能提前知1 Y Z B道哪些商家哪些商品要参与秒杀,可以根据提报的商品提前生成静态页面并上传到CDN预热,提报的商品库存也需要8 3 7 X ?提前预热,可以将商品库存在活动开始前预热到Redis,避免秒杀开始后大量的缓存穿透。

如何设计电商行业亿级用户秒杀系统

2,部署隔离。秒杀相关服务和日常服务要分组部署,不能因E D l为秒杀出问题影响日常售卖业务。可以申请单独的秒杀域名,从网络入口层就开始分流。网关也单独部署,秒杀走自己单独的网关,从而避免日常网关受到影响。秒杀可以复用订单,库存,支付等日常服务,只是需要一些小的改造(比如下单流程走消息队列,批量写入订单库,以及在Redis中扣减库存)。

如何设计电商行业亿级用户秒杀系统

3,数据隔离。为了避免秒杀活动影响到日常售卖业务,Redis缓存需要单独部署,甚至数据库也需要单独部署!数据隔离后,秒杀剩余的库存怎么 [ v &办?秒杀活动结束后,剩余库f r b e d a ) { a存可T ? | 1 j | v C e以归还到日常库存继续做为普通商品售卖。/ 4 e ~ K 3 ` 3 I数据隔离后,秒杀订单和日常u 1 2 V a G 4订单不在相同的数据库,之( 6 P 3 J Z - B后的订单查询怎么展示?可以在创建秒杀订单后发消息到消息队列,日常订单服务采取拉的方式消费消息& j c 7 y 8,这时日常订单服务是主动方,可以采用线程池的方式,根据机器的性能来增加或缩小线~ w Z P ] J p 9程池的大小,控制拉取消息的速度,来控制订单数据库的写入压力。

网络:

秒杀前要和网络运营商、CDN服务商提前申请带宽。

还有哪些细节要考虑:

1.如何避免超卖?如果在redis中扣减库存,可以利用decr命令扣减库存,decr是原子操作,在分d z n * M 2 !布式环境下也不会有并发问题,decr扣减库存后,判断返回值,如果返回值小于0,扣减库存失$ X : 0 / o败,秒杀也就失败了;如果在数据库中扣减库存可以在where后面加上库存g u h = | E F ,大于0的条件,来避免库存被减成负值。这样就可以避免超卖情况发生了。

2.接口防刷,前面已经提到过,在网关层对下单等接口按userId R = t g X )D限流。

3.网关层除了对userH d & F % p j zID做限流外,还要做整体限流。在实际访问量超过预估访问量时,整体限流可以起到保护作用,避免系统被压垮。

4.防止重复下0 K ; : | # O单,按usM k [ $ 6 ferID限流已经起到了防止重复u J m G / F下单的作用。假如限制同一个用户10分钟能下一次单,一般情况下10分钟内,商品早已经被抢光了,用户也就没有再次下单的机会了。

5.X U f v } D Y M可以结合风控系统,在网关层把羊毛党等有问题的用户请求直接拒掉。

6.可以在网关层上面再加一层防火墙或者高防服务,来防御DDos等分布式网络攻击。