您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

这一次,彻底弄懂“秒杀系统”

时间:2019-09-24 10:09:14  来源:  作者:

【51CTO.com原创稿件】说到“秒杀”,恐怕大多数人想到的就是“双 11”,“促销”,“买买买”等火爆的场面吧。

 

这一次,彻底弄懂“秒杀系统”

 

 

图片来自 Pexels

大家为了打折商品蜂拥而至,造成电商网站一片繁华的景象。但作为程序员的我们,看到的却是背后的高并发和可靠性。无论你处在软件开发的哪个阶段,都希望能够设计一套属于自己的秒杀系统。

今天我们一起来看看,一套秒杀系统在架构设计上需要有哪些考量:

  • 秒杀场景的特点
  • 系统隔离的设计思路
  • 客户端设计
  • 代理层设计
  • 应用层设计
  • 数据库设计
  • 压力测试
  • 总结

秒杀场景的特点

秒杀场景是电商网站定期举办的活动,这个活动有明确的开始和结束时间,而且参与互动的商品是事先定义好了,参与秒杀商品的个数也是有限制的。同时会提供一个秒杀的入口,让用户通过这个入口进行抢购。

总结一下秒杀场景的特点:

  • 定时开始,秒杀时大量用户会在同一时间,抢购同一商品,网站瞬时流量激增。
  • 库存有限,秒杀下单数量远远大于库存数量,只有少部分用户能够秒杀成功。
  • 操作可靠,秒杀业务流程比较简单,一般就是下订单减库存。库存就是用户争夺的“资源”,实际被消费的“资源”不能超过计划要售出的“资源”,也就是不能被“超卖”。

系统隔离的设计思路

在分析秒杀的特点后,我们发现秒杀活动是有计划的,并且在短时间内会爆发大量的请求。为了不影响现有的业务系统的正常运行,我们需要把它和现有的系统做隔离。

即使秒杀活动出现问题也不会影响现有的系统。隔离的设计思路可以从三个维度来思考。

  • 业务隔离
  • 技术隔离
  • 数据库隔离

业务隔离

既然秒杀是一场活动,那它一定和常规的业务不同,我们可以把它当成一个单独的项目来看。在活动开始之前,最好设计一个“热场”。

“热场”的形式多种多样,例如:分享活动领优惠券,领秒杀名额等等。“热场”的形式不重要,重要的是通过它获取一些准备信息。

例如:有可能参与的用户数,他们的地域分布,他们感兴趣的商品。为后面的技术架构提供数据支持。

技术隔离

 

这一次,彻底弄懂“秒杀系统”

 

 

技术隔离架构图

前面有了准备工作,那么从技术上需要有以下几个方面的考虑:

  • 客户端,前端秒杀页面使用专门的页面,这些页面包括静态的 html 和动态的 JS,他们都需要在 CDN 上缓存。
  • 接入层,加入过滤器专门处理秒杀请求,即使我们扩展再多的应用,使用再多的应用服务器,部署再多的负载均衡器,都会遇到支撑不住海量请求的时候。

所以,在这一层我们要考虑的是如何做好限流,当超过系统承受范围的时候,需要果断阻止请求的涌入。

  • 应用层,瞬时的海量请求好比请求的“高峰”,我们架构系统的目的就是“削峰”。

需要使用服务集群和水平扩展,让“高峰”请求分流到不同的服务器进行处理。同时,还会利用缓存和队列技术减轻应用处理的压力,通过异步请求的方式做到最终一致性。

由于是多线程操作,而且商品的额度有限,为了解决超卖的问题,需要考虑进程锁的问题。

数据库隔离

秒杀活动持续时间短,瞬时数据量大。为了不影响现有数据库的正常业务,可以建立新的库或者表来处理。

在秒杀结束以后,需要把这部分数据同步到主业务系统中,或者查询表中。如果数据量特别巨大,到千万级别甚至上亿,建议使用分表或者分库。

客户端设计

上面提到的三个隔离维度中,我们对技术维度是最为关心的。如果说浏览器/客户端是用户接触“秒杀系统”的入口,那么在这一层提供缓存数据就是非常必要的。

在设计之初,我们会为秒杀的商品生成专门的商品页面和订单页面。这些页面以静态的 HTML 为主,包括的动态信息尽量少。

从业务的角度来说,这些商品的信息早就被用户熟识了,在秒杀的时候,他们关心的是如何快速下单。

既然商品的详情页面和订单页面都是静态生成的,那么就需要定义一个 URL,当要开始秒杀之前,开放这个 URL 给用户访问。

为了防止“程序员或者内部人员”作弊,这里的地址可以通过时间戳和 Hash 算法来生成,也就是说这个地址只有系统知道,到了快秒杀之前才由系统发放出去。

有人说浏览器/客户端如果存放的都是静态页面,那么“控制开始下单”的按钮,以及发送“下单请求”的按钮,也是静态的吗?

答案是否定的,其实静态页面是方便客户端好缓存,下单的动作以及下单时间的控制还是在服务器端。

只不过是通过 JS 文件的方式发送给客户端,在快要秒杀之前,会把这部分 JS 下载到客户端。

因为,其业务逻辑很少,基本只包括时间,用户信息,商品信息等等。所以,其对网络的要求不高。

同时,在网络设计上,我们也会将 JS 和 HTML 同时缓存在 CDN 上面,让用户从离自己最近的 CDN 服务器上获取这些信息。

为了避免秒杀程序参与秒杀,在客户端也会设计一些问答或者滑块的功能,减少此类机器人对服务器的压力。

 

这一次,彻底弄懂“秒杀系统”

 

 

秒杀系统前端设计简图

代理层设计

说完了秒杀系统的前端设计,请求自然地来到了代理层。由于用户的请求量大,我们需要用负载均衡加上服务器集群,来面对如此空前的压力。

 

这一次,彻底弄懂“秒杀系统”

 

 

代理层三大功能简图

在这一层是可以做缓存,过滤和限流的:

  • 缓存,以 Nginx 为例,它可以缓存用户的信息。假设用户信息的修改没有那么频繁,即使有类似的修改也可以通过更新服务来刷新。总比从服务器上获取效率要高得多。
  • 过滤,既然缓存了用户信息,这里就可以过滤掉一些不满足条件的用户。注意,这里的用户信息的过滤和缓存只是一个例子。

主要想表达的意思是,可以将一些变化不频繁的数据,提到代理层来缓存,提高响应的效率。

同时,还可以根据风控系统返回的信息,过滤一些疑似机器人或者恶意请求。例如:从固定 IP 过来的,频率过高的请求。最重要的就是在这一层,可以识别来自秒杀系统的请求。

如果是带有秒杀系统的参数,就要把请求路由到秒杀系统的服务器集群。这样才能和正常的业务系统分割开来。

  • 限流,每个服务器集群能够承受的压力都是有限的。代理层可以根据服务器集群能够承受的最大压力,设置流量的阀值。

阀值的设置可以是动态调整的。例如:集群服务器中有 10 个服务器,其中一台由于压力过大挂掉了。

此时就需要调整代理层的流量阀值,将能够处理的请求流量减少,保护后端的应用服务器。

当服务器恢复以后,又可以将阀值调回原位。可以通过 Nginx+Lua 合作完成,Lua 从服务注册中心读取服务健康状态,动态调整流量。

应用层设计

“秒杀系统”秒杀的是什么?无非是商品。对于系统来说就是商品的库存,购买的商品一旦超过了库存就不能再卖了。

防止超卖

超过了库存还可以卖给用户,这就是“超卖”,也是系统设计需要避免的。为了承受大流量的访问,我们用了水平扩展的服务,但是对于他们消费的资源“库存”来说,却只有一个。

为了提高效率,会将这个库存信息放到缓存中。以流行的 redis 为例,用它存放库存信息,由多个线程来访问就会出现资源争夺的情况。也就是分布式程序争夺唯一资源,为了解决这个问题我们需要实现分布式锁。

假设这里有多个应用响应用户的订单请求,他们同时会去访问 Redis 中存放的库存信息,每接受用户一次请求,都会从 Redis 的库存中减去 1 个商品库存量。

当任何一个进程访问 Redis 中的库存资源时,其他进程是不能访问的,所以这里需要考虑锁的情况(乐观,悲观)。

 

这一次,彻底弄懂“秒杀系统”

 

 

Redis 缓存承载库存变量

如果锁长期没有释放,需要考虑锁的过期时间,需要设置两个超时时间:

  • 资源本身的超时时间,一旦资源被使用一段时间还没有被释放,Redis 会自动释放掉该资源给其他服务使用。
  • 服务获取资源的超时时间,一旦一个服务获取资源一段时间后,不管该服务是否处理完这个资源,都需要释放该资源给其他服务使用。

订单处理流程

这里的“扣减服务”完成了最简单的扣减库存工作,并没有和其他项目服务打交道,更没有访问数据库。

 

这一次,彻底弄懂“秒杀系统”

 

 

订单流程示意图

后面的流程相对比较复杂,我们先看图,根据图示来讲解:

  • 首先,扣减服务作为下单流程的入口,会先对商品的库存做扣减。同样它会检查商品是否还有库存?
  • 由于订单对应的操作步骤比较多,为了让流量变得平滑,这里使用队列存放每个订单请求,等待订单处理服务完成具体业务。
  • 订单处理服务实现多线程,或者水平扩展的服务阵列,它们不断监听队列中的消息。一旦发现有新订单请求,就取出订单进行后续处理。

注意,这里可以加入类似 ZooKeeper 这样的服务调度来帮助,协调服务调度和任务分配。

  • 订单处理服务,处理完订单以后会把结果写到数据库。写数据库是 IO 操作,耗时长。
  • 所以,在写数据库的同时,会把结果先写入缓存中,这样用户是可以第一时间查询自己是否下单成功了。
  • 结果写入数据库,这个操作有可能成功也有可能失败。
  • 为了保证数据的最终一致性,我们用订单结果同步的服务不断的对比,缓存和数据库中的订单结果信息。

一旦发现不一致,会去做重试操作。如果重试依旧不成功,会重写信息到缓存,让用户知道失败原因。

  • 用户下单以后,焦虑地刷新页面查看下单的结果,实际上是读到的缓存上的下单结果信息。

虽然,这个信息和最终结果有偏差,但是在秒杀的场景,要求高性能是前提,结果的一致性,可以后期补偿。

数据库设计

讲完了秒杀的处理流程,来谈谈数据库设计要注意的点。

数据估算

前面说了秒杀场景需要注意隔离,这里的隔离包括“业务隔离”。就是说我们在秒杀之前,需要通过业务的手段,例如:热场活动,问卷调查,历史数据分析。通过他们去估算这次秒杀可能需要存储的数据量。

这里有两部分的数据需要考虑:

  • 业务数据
  • 日志数据

前者不言而喻是给业务系统用的。后者,是用来分析和后续处理问题订单用的,秒杀完毕以后还可以用来复盘。

分表分库

对于这些数据的存放,需要分情况讨论,例如,MySQL 单表推荐的存储量是 500W 条记录(经验数字)。

如果估算的时候超过了这个数据,建议做分表。如果服务的连接数较多,建议进行分库的操作。

数据隔离

由于大量的数据操作是插入,有少部分的修改操作。如果使用关系型数据来存储,建议用专门的表来存放,不建议使用业务系统正在使用的表。

这个开头提到了,数据隔离是必须的,一旦秒杀系统挂了,不会影响到正常业务系统,这个风险意识要有。表的设计除了 ID 以外,最好不要设置其他主键,保证能够快速地插入。

数据合并

由于是用的专用表存储,在秒杀活动完毕以后,需要将其和现有的数据做合并。其实,交易已经完成,合并的目的也就是查询。

这个合并需要根据具体情况来分析,如果对于那些“只读”的数据,对于做了读写分离的公司,可以导入到专门负责读的数据库或者 NoSQL 数据库中。

压力测试

构建了秒杀系统,一定会面临上线,那么在上线之前压力测试是必不可少的。

我们做压力测试的目的是检验系统崩溃的边缘在哪里?系统的极限在哪里?

这样才能合理地设置流量的上限,为了保证系统的稳定性,多余的流量需要被抛弃。

压力测试的方法

合理的测试方法可以帮助我们对系统有深入的了解,这里介绍两种压力测试的方法:

  • 正压力测试
  • 负压力测试

正压力测试。每次秒杀活动都会计划,使用多少服务器资源,承受多少的请求量。

可以在这个请求量上面不断加压,直到系统接近崩溃或者真正崩溃。简单的说就是做加法。

 

这一次,彻底弄懂“秒杀系统”

 

 

正压力测试示意图

负压力测试。在系统正常运行的情况下,逐步减少支撑系统的资源(服务器),看什么时候系统无法支撑正常的业务请求。

例如:在系统正常运行的情况下,逐步减少服务器或者微服务的数量,观察业务请求的情况。说白了就是做减法。

 

这一次,彻底弄懂“秒杀系统”

 

 

负压力测试示意图

压力测试的步骤

 

这一次,彻底弄懂“秒杀系统”

 

 

测试步骤

有了测试方法的加持,我们来看看需要遵循哪些测试步骤。下面的操作偏套路化,大家在其他系统的压力测试也可以这么做,给大家做个参考。

第一,确定测试目标。与性能测试不同的是,压力测试的目标是,什么时候系统会接近崩溃。比如:需要支撑 500W 访问量。

第二,确定关键功能。压力测试其实是有重点的,根据 2/8 原则,系统中 20% 的功能被使用的是最多的,我们可以针对这些核心功能进行压力测试。例如:下单,库存扣减。

 

这一次,彻底弄懂“秒杀系统”

 

 

关注核心服务

第三,确定负载。这个和关键服务的思路一致,不是每个服务都有高负载的,我们的测试其实是要关注那些负载量大的服务,或者是一段时间内系统中某些服务的负载有波动。这些都是测试目标。

第四,选择环境,建议搭建和生产环境一模一样的环境进行测试。

第五,确定监视点,实际上就是对关注的参数进行监视,例如 CPU 负载,内存使用率,系统吞吐量等等。

第六,产生负载,这里需要从生产环境去获取一些真实的数据作为负载数据源,这部分数据源根据目标系统的承受要求由脚本驱动,对系统进行冲击。

建议使用往期秒杀系统的数据,或者实际生产系统的数据进行测试。

第七,执行测试,这里主要是根据目标系统,关键组件,用负载进行测试,返回监视点的数据。

建议团队可以对测试定一个计划,模拟不同的网络环境,硬件条件进行有规律的测试。

第八,分析数据,针对测试的目的,对关键服务的压力测试数据进行分析得知该服务的承受上限在哪里。

对一段时间内有负载波动或者大负载的服务进行数据分析,得出服务改造的方向。

总结

秒杀系统的特点,并发量大,资源有限,操作相对简单,访问的都是热点数据。因此,我们需要把它从业务,技术,数据上做隔离,保证不影响到现有的系统。

因此,架构设计需要分几层来考虑,从客户请求到数据库存储,到最后上线前的压力测试。

 

这一次,彻底弄懂“秒杀系统”

 

 

简易的思维导图送给大家

思考顺序如下,客户端→代理层→应用层→数据库→压力测试:

客户端 90% 静态 HTML+10% 动态 JS;配合 CDN 做好缓存工作。

接入层专注于过滤和限流。

应用层利用缓存+队列+分布式处理好订单。

做好数据的预估,隔离,合并。

上线之前记得进行压力测试。

作者:崔皓

简介:十六年开发和架构经验,曾担任过惠普武汉交付中心技术专家,需求分析师,项目经理,后在创业公司担任技术/产品经理。善于学习,乐于分享。目前专注于技术架构与研发管理。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】



Tags:秒杀系统   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
导论曾经被问过好多次怎样实现秒杀系统的问题。昨天又在CSDN架构师微信群被问到了。因此这里把我设想的实现秒杀系统的价格设计分享出来。供大家参考。秒杀系统的架构设计秒...【详细内容】
2021-03-03  Tags: 秒杀系统  点击:(175)  评论:(0)  加入收藏
秒杀业务分析正常电子商务流程: 查询商品 创建订单 扣减库存 更新订单 付款 卖家发货秒杀业务的特性 低廉价格 大幅推广 瞬时售空 一般是定时上架 时间短、瞬时并发量高秒杀...【详细内容】
2020-07-04  Tags: 秒杀系统  点击:(125)  评论:(0)  加入收藏
究竟什么样的系统算是高并发系统?今天,我们就一起解密高并发业务场景下典型的秒杀系统的架构,结合高并发专题下的其他文章,学以致用。...【详细内容】
2020-04-20  Tags: 秒杀系统  点击:(54)  评论:(0)  加入收藏
前言Redis在互联网技术存储方面使用如此广泛,几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。作为一个在互联网公司面一次拿一次Offer...【详细内容】
2020-03-11  Tags: 秒杀系统  点击:(168)  评论:(0)  加入收藏
简单来说,秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。从架构视角来看,秒杀系统本质上是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量...【详细内容】
2019-11-25  Tags: 秒杀系统  点击:(71)  评论:(0)  加入收藏
前言秒杀大家都不陌生。自2011年首次出现以来,无论是双十一购物还是 12306 抢票,秒杀场景已随处可见。简单来说,秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过...【详细内容】
2019-11-19  Tags: 秒杀系统  点击:(65)  评论:(0)  加入收藏
【51CTO.com原创稿件】说到“秒杀”,恐怕大多数人想到的就是“双 11”,“促销”,“买买买”等火爆的场面吧。 图片来自 Pexels大家为了打折商品蜂拥而至,造成电商网站一片繁华...【详细内容】
2019-09-24  Tags: 秒杀系统  点击:(148)  评论:(0)  加入收藏
#0 系列目录# 秒杀系统架构 秒杀系统架构分析与实战#1 秒杀业务分析# 正常电子商务流程(1)查询商品;(2)创建订单;(3)扣减库存;(4)更新订单;(5)付款;(6)卖家发货 秒杀业务的特性(1)低廉价格;(2)大幅...【详细内容】
2019-08-21  Tags: 秒杀系统  点击:(209)  评论:(0)  加入收藏
什么是秒杀?“秒杀”是商家在特定时间点进行促销的一种运营手段,体现在系统层面,是指一个Web系统,在一秒钟收到数以万计的用户请求,来抢购数量有限的促销产品。本质上,秒杀系统就...【详细内容】
2019-08-08  Tags: 秒杀系统  点击:(220)  评论:(0)  加入收藏
内容:“商品秒杀”功能模块是建立在“商品详情”功能模块的基础之上,对于这一功能模块而言,其主要的核心流程在于:前端发起抢购请求,该请求将携带着一些请求数据:待秒杀Id跟当前用...【详细内容】
2019-07-23  Tags: 秒杀系统  点击:(350)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(5)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(9)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(21)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(17)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(17)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条