如何设计一个合格的高并发秒杀系统

这篇具有很好参考价值的文章主要介绍了如何设计一个合格的高并发秒杀系统。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、前言

在前面的文章中,详细阐述了建设秒杀系统的目标与存在的挑战,并且简单罗列了如何应对这些挑战的方式。本章,就详细阐述对秒杀系统存在挑战的应对之道,最终构建出兼具高并发、高性能和高可用的秒杀系统。心中不仅了解建设秒杀系统存在的挑战,更清楚的知道这些挑战的应对之道,正所谓:知己知彼,百战不殆,方案了然于胸,自然有应对之法。

二、本章诉求

一般一套成熟并且稳定、经得起实际大促场景考验的秒杀系统,都是经过不断迭代、优化和演化而来的。对于设计和研发秒杀系统的技术人员来说,心中一定要清晰的知晓建设秒杀系统存在的挑战,以及针对这些挑战的应对之法。

三、应对之道

对于秒杀系统,站在技术人员的角度,相信大家多多少少对秒杀系统有所了解了。既然建设秒杀系统存在着种种的困难和挑战,那我们就需要从整体上分析这些挑战的应对之法,而不是在真正开发秒杀系统时,再去临时想方案,查漏补缺,切忌头痛医头、脚痛医脚。

从总体上说,我们应对秒杀系统挑战时,心中要有一杆秤,在设计秒杀系统时,一定要做到分离、削峰限流、快速响应、准确一致、稳定可靠、全链路压测。

如何设计一个合格的高并发秒杀系统

接下来,就针对每种应对之道进行详细的阐述。

四、分离之道

分离之道中,重点在于一个“”字,主要包括:前后端资源分离、接口分离,数据分离、业务分离、系统分离、流量分离。

如何设计一个合格的高并发秒杀系统

4.1 资源分离

资源分离,主要指的是前后端的资源分离。目前,除了一些非常老旧的系统之外,一般在开发互联网项目过程中,都会采用前后端分离的架构模式,这也是比较普遍的做法。在秒杀系统中,将前端资源分离出来,部署时可以直接推送到CDN服务器,CDN服务器全国各地都有,用户在访问系统时,可以从就近的CDN服务器上拉取对应的资源,能够极大的增强系统的性能。

4.2 接口分离

接口分离包含两个方面:一个是秒杀接口与其他接口分离,一个是高频访问接口与低频访问接口分离。

对于秒杀系统的接口来说,在设计上一定要与其他的接口进行分离,不要让秒杀系统的接口与其他业务的接口互相关联引用,避免秒杀系统的瞬时高并发流量对其他接口造成影响。

就秒杀系统而言,并不是每个接口的访问频次都一样,一本情况下,商品详情页、结算页和秒杀下单接口的访问频次要远远大于支付接口的访问频次。在设计上一定要将这些接口进行区分隔离,对高频访问的接口进行单独的性能优化。

4.3 数据分离

数据分离也会包含两个方面:一个是秒杀数据与其他数据分离,一个是动态数据与静态数据分离。

一般情况下,秒杀数据瞬时的增长率会远远大于其他数据,在数据上进行分离,可以对秒杀数据的存储设施进行单独的针对性优化,不能让秒杀数据对其他数据产生影响,在数据层面对秒杀系统进行专有部署。

就秒杀系统而言,本身也会存在着动态数据和静态数据。动态数据在秒杀期间会容易发生变更,比如秒杀系统的品类、商品的库存和上下架的状态等,都是的动态数据,这些动态数据对时间比较敏感。而像秒杀结果等与用户本身相关的一些数据,可以称为静态数据,因为这些数据在整个秒杀活动期间,基本不会发生变化。

在设计上,需要对这些动态数据和静态数据进行分离,因为数据的更新频率不同,在优化手段和架构设计上也会存在着差异。对动态数据和静态数据进行分离后,也可以将服务端产生的静态数据推送到CDN。

4.4 业务分离

秒杀业务不同于普通的商城业务,秒杀业务的特点就是流量大、持续的时间短,在设计秒杀系统时,需要充分考虑到不同业务之间的影响,做到秒杀业务与其他业务之间的分离。

4.5 系统分离

秒杀系统与其他系统不同,秒杀系统需要承接瞬时高并发流量,而其他大部分系统的流量则比较平缓。一旦将秒杀系统和其他业务系统部署到一起的话,势必会对其他业务系统造成比较大的影响,所以,需要将秒杀系统与其他业务系统进行分离处理。

在系统分离层面,一般在大厂的秒杀系统中会将秒杀详情页系统、秒杀结算页系统、购物车系统和订单系统进行分离,并且会申请单独的域名和负载均衡器等,并且会对相应的微服务集群进行分组隔离。

4.6 流量分离

看到这里,相信大家对秒杀系统的印象更加深刻了。没错,秒杀系统的瞬时流量是巨大的,如果秒杀系统的流量与其他业务系统的流量不加以分离处理,其他系统势必会由于巨大的瞬时流量而导致各种连锁问题,所以,在设计上,务必将秒杀系统与其他业务系统的流量进行分离。

五、限流之道

限流主要是对流量进行限制,对于秒杀这种业务场景来说,流量是瞬时且巨大的,期间流量会在几秒钟之内爬升到峰值,然后马上又掉下来,形成巨大的毛刺峰值,对系统费资源的消耗也是瞬时且巨大的,需要对这些流量进行限制和管控。通常的应对方法主要有:提前预约秒杀、打散客户端流量、消息队列、网关限流、API限流、应用层限流、安全校验、活动校验,秒杀商品校验、秒杀资格校验、风控校验,大厂策略。

如何设计一个合格的高并发秒杀系统

5.1 提前预约秒杀

为秒杀系统设计一个预约功能,或者单独设计一个预约系统,用户要想参与秒杀抢购,则需要提前预约商品的抢购,这样可以在参与抢购的用户基数上进行控制,能够提前锁定参与秒杀抢购的用户,而不是整个平台中所有的用户都能参与抢购。这样可以通过将抢购的用户访问控制在预约人数之内,在一定程度上能够大大减少秒杀的峰值流量,对秒杀系统起到一定的防护作用。

5.2 打散客户端流量

一般秒杀系统的客户端也会包含:PC、H5、App和小程序,作为秒杀流量的入口,可以在这些入口端设置答题、验证码和滑块等方式将流量打散,因为每个人输入问答题答案、验证码和滑块的手速不同,就会将瞬时的大并发流量分散到一小段时间内。在秒杀的场景中,不要小看这些处理方式,即使将流量分摊到一秒或者几百毫秒的时间内,也会将流量峰值降低一个甚至几个量级。

例如,在没有将客户端浏览打散的情况下,流量峰值为100万QPS,使用答题、验证码和滑块的方式将流量打散后,流量峰值可能就会下降到80万QPS、60万QPS甚至更低,对秒杀系统能过起到有效的防护作用。

另外,使用问答题、验证码和滑块的方式也能够快速拦截部分刷单流量、防止机器作弊,起到一定的防刷作用。

注意:目前像阿里这样的头部电商平台,已经不会在客户端使用问答题、验证码和滑块等方式将流量打散,更倾向于采用非公平的策略,使用有损逐级限流和分层过滤的方式来达到系统限流的目的。

5.3 消息队列

使用消息队列来削峰填谷,通过消息队列可以将同步的请求改造成异步请求,将超过下游系统处理范围的流量暂时存入消息队列中,下游的系统可以根据自身处理数据的性能来消费队列中的数据。

使用消息队列对抢购下单异步化之后,前端不能及时知晓秒杀的结果数据,需要前端定期查询秒杀的结果数据反馈给用户。在使用消息队列设计异步抢购流程时,有个小技巧:就是前面的请求将商品的库存消耗完之后,在商品库存的缓存中设置一个特殊占位符,让后续的请求能够快速失败,而不再进行后续的业务逻辑处理。

可以使用RocketMQ、Kafka和RabbitMQ等消息中间件来实现请求的异步化和削峰填空,具体使用哪种消息中间件可以根据自身业务进行实际评估。

5.4 网关限流

网关一般是一个系统的入口,可以在网关层对流量进行限流,对超出当前系统流量阈值的请求根据一定的策略进行处理,例如拒绝超出当前系统流量阈值的请求,快速返回失败,也可以将超出阈值的流量缓存起来进行排队,按照一定的顺序消费这些请求,会对下游的业务系统起到一定的防护作用。

5.5 API限流

API限流也就是对接口进行限流,可以使用Google提供的RateLimiter开源包,实现对应的限流策略,在系统中具体的API代码里进行限流。这种方式可以做到针对特定的API接口进行限流。

5.6 应用层限流

应用层的限流可以通过对线程池的限流来实现,实现线程池的限流时,主要是设置并发数限流,可以通过自定义线程池,配置最大的连接数,以请求队列的长度和拒绝策略等参数进行限流,如果队列已满,并且已经达到最大的线程数,多余的请求就会根据具体的拒绝策略进行处理,以达到限流的目的和效果。

5.7 安全校验

安全校验就是要识别出请求的流量哪些是安全流量,哪些是不安全的流量,这里说的不安全的流量指的是友商、黄牛党或者不怀好意的用户发起的刷单流量、CC攻击等,这种流量对系统是有害的,能够消耗大量的系统资源,为系统造成比较大的压力,并且这种方式挤占了正常抢购的通道,对正常参与秒杀活动的用户是不公平的。

5.8 活动校验

活动校验就是接收到请求时,对活动数据进行校验,核对活动是否已经结束、是否下架等等,如果活动已经结束或者已经下架,则在缓存中设置特殊的占位符,对后续的请求进行快速失败处理,不再进行后续的逻辑处理。

做活动校验的原因是用户在客户端看到活动有效,当流量达到服务端时,活动可能已经结束或者失效了,所以需要做活动的校验处理。

5.9 秒杀品校验

秒杀品校验就是在接收到请求时,对当前的商品信息进行校验,核对当前商品是否有效,库存是否充足等。如果商品不再有效、或者库存已经消耗完毕,则在缓存中设置特殊的占位符,对后续的请求进行快速失败处理,不再进行后续的逻辑处理。

做秒杀品校验的原因是用户在客户端看到活动有效,当流量达到服务端时,秒杀品可能已经结束或者失效了,所以需要做秒杀品的校验处理。

5.10 秒杀资格校验

秒杀资格校验主要是对参与秒杀的用户的资格进行校验,比如设计了预约环节时,只有提前预约过秒杀抢购的用户才能参与秒杀。再比如,针对当前活动设置了只能秒杀一次的用户,如果当前用户存在本次活动的秒杀记录,就不再允许二次秒杀等等。还有就是如果对秒杀品设置了只针对某些地区开放秒杀活动,则需要判断用户的所在地是否在开放的地区,如果不在开放秒杀的地区,则不允许抢购等等。

另外,在秒杀的资格校验上,可能存在同一个用户不断伪造请求的现象,需要加强用户唯一身份的校验等逻辑。

5.11 风控校验

一个成熟稳定的秒杀系统的背后会接入风控系统,对整个秒杀活动进行风控处理,风控系统的建设不是一朝一夕就能完成的,建立风控的过程也是比较困难的,这需要建立在大量数据的基础之上,不断的完善用户的画像,需要通过复杂的业务场景的考验,不断的修正风控模型。

5.12 大厂策略

像阿里这种头部互联网公司,其秒杀系统处了会使用上述限流之道进行系统限流外,其处于兼顾用户体验和系统资源的考虑,一般不会采用问答题、验证码或者滑块的方式来打散客户端流量,更倾向于采用非公平的策略,使用有损逐级限流和分层过滤的方式来达到系统限流的目的。

六、快速响应之道

秒杀的场景虽然是高并发、大流量的业务场景,但是在秒杀场景中,需要快速响应用户的请求,不能让用户出现长时间等待的情况,这就需要在秒杀系统的设计上采用一定的策略。对于快速响应来说,可以从多用缓存、本地缓存、分布式缓存、数据尽量少、计算尽量少和流程尽量简单几个方面进行设计。

如何设计一个合格的高并发秒杀系统

6.1 多用缓存

像秒杀这种在高并发大流量场景下要求极致体验的系统,缓存是必不可少的,无论是对前端资源还是对后端数据来说,使用缓存都能够极大的提升系统的性能。同时,使用缓存也能够对系统进行一定的防护。

如果系统中没有使用缓存,或者发生了缓存穿透或者雪崩,瞬时的大量请求直接打到数据库,那数据库连接会被瞬间耗尽而导致不可用,进而导致严重的连锁反应,整个系统都会被拖垮,所以,使用缓存是非常重要的。

6.2 本地缓存

在秒杀系统中,为了进一步提升系统的性能,会将一部分非常热点的数据缓存在本地的JVM内存中,接收到请求后,会先从本地缓存中获取数据,如果本地缓存不存在要获取的数据,就会到分布式缓存中进行查询。

6.3 分布式缓存

除了本地缓存外,分布式缓存也是秒杀系统必不可少的,本地缓存的数据有限,只能缓存一部分极度热点的数据,并且这些极度热点的数据开始在本地缓存中也不一定存在,这就需要分布式缓存的存在,如果本地缓存中没有数据,就到分布式缓存查询,尽最大努力提升系统的性能。

6.4 数据尽量少

对于提升系统的响应性能来说,光有缓存还不够,还要在处理的数据上要尽量少,不要查询或者返回无关紧要的数据。因为缓存只是提升了IO的执行效率,但是除了要提升IO的执行效率,还要提升数据在网络中的传输效率、以及内存和磁盘的读写效率。这些都要求我们处理的数据要尽量少。

6.5 计算尽量少

除了数据尽量少以外,对于数据的计算操作也要尽量少,尽量不涉及复杂的计算操作,复杂的计算操作会消耗大量的CPU资源,会极大的影响系统的响应性能。

6.6 流程尽量简单

秒杀系统在流程设计中要尽量简单,不要涉及到复杂的业务流程,流程越简单,处理的业务逻辑越少,性能就越高效。

七、准确一致之道

缓存是秒杀系统必不可少的,但是使用缓存之后,就会出现数据一致性的问题,这些数据一致性的问题,就是需要考虑和处理的,主要包含:缓存与数据库一致、本地缓存与分布式缓存一致、商品库存与订单数据一致、前端与后端数据一致。

如何设计一个合格的高并发秒杀系统

7.1 缓存与数据库一致

使用缓存能够极大的提升系统的性能,但是使用了缓存之后,需要在确保缓存中的数据和数据库中的数据是一致的。这种一致性需要根据场景决定是强一致性还是弱一致性,亦或是最终一致性。

7.2 本地缓存与分布式缓存一致

本地缓存和分布式缓存都能够提升数据的性能,对于极度热点数据来说,最好是存储在本地缓存中来提升系统的性能,但是这就需要考虑本地缓存与分布式缓存数据的一致性问题。

7.3 商品库存与订单一致

这里说的商品库存与订单一致,指的是商品已经消耗的库存数量与订单中的商品数量一致,不能出现超卖问题,这就需要在秒杀系统的设计中,充分考虑到商品库存的扣减问题。

7.4 前端与后端数据一致

前端与后端的数据一致,指的是在秒杀过程中尽量做到前端的数据与后端的数据保持一致,这里说的一致,就不是强一致了,而是最终一致。因为参与秒杀的用户很多,可能会出现某个用户在客户端看到的商品库存剩余100件,发起秒杀抢购的请求后,请求发送到服务端,服务端检测到商品库存已经耗光,就会返回库存不足或者秒杀已结束的提示,这种场景就可以归类为最终一致。

八、稳定可靠之道

一个系统的稳定性是重中之重要考虑的问题,一个秒杀系统必须要具备高度的稳定性,要想满足系统的稳定性,可以从隔离策略和监控的角度来保证系统的稳定性。隔离可以从业务隔离、系统隔离和数据隔离的角度进行考虑,监控就可以从监控数据库与基础指标、JVM指标和中间件等指标的角度进行考虑。

如何设计一个合格的高并发秒杀系统

8.1 业务隔离

秒杀系统在业务上与其他系统进行隔离,对于参与秒杀的商品来说,一般会在秒杀活动开始前,提前进行提报,并且指定详细的营销策划和方案。对于参与用户来说,提前预约,可以提前识别流量和系统的并发数,根据具体情况评估是否需要扩容、是否需要降级或者调整限流策略。

8.2 系统隔离

对于被流量冲击比较大的核心系统进行物理隔离,链路末端的系统,经过前面的削峰限流之后,流量就比较可控了,可以不做物理隔离,在逻辑上进行隔离即可。在大厂中,一般会将秒杀的商详页系统、秒杀结算页系统、购物车系统和订单系统单独隔离出来。

8.3 数据隔离

对于秒杀系统的数据服务,例如Redis集群、MySQL集群等要单独隔离部署,做到秒杀数据与其他业务数据的隔离。

除此之外,还要将流量正确的路由到秒杀专有的环境中。

8.4 监控数据库与基础指标

除了通过隔离策略增强系统的稳定性之外,还要时刻关注系统的风险指标,对数据库、CPU使用率、内存使用率、负载、网卡、磁盘、IO、网络波动等进行监控。

8.5 监控JVM指标

监控JVM的指标可以包含:Young GC和Full GC的次数和耗时,线程池的线程数和等待队列,运行中的线程,死锁的线程,以及JVM的堆栈使用情况等等。

8.6 监控中间件指标

监控中间件的指标,一般情况下可以缓存的容量、QPS和RT进行监控,对于数据库的QPS、容量和连接池进行监控,对消息中间件的QPS、RT以及消息的堆积情况进行监控,对整个交易链路的分支系统进行监控等等。

九、全链路压测之道

对于秒杀这种系统高并发、大流量的系统来说,单一的测试功能和对交易链路上某一部分功能都不能测试出整个秒杀系统的性能瓶颈点,要知道木桶能不能装满水是取决于最短的木板,对于系统来说也是,整体性能也是取决于整个交易链路上性能最低的一环。所以,需要对秒杀系统进行全链路压测。根据实际压测出来的数据进行针对性的优化和调整。

十、总结

本章,主要是对秒杀系统高并发大流量的挑战给出了应对之道,从总体上说,我们应对秒杀系统挑战时,心中要有一杆秤,在设计秒杀系统时,一定要做到分离、削峰限流、快速响应、准确一致、稳定可靠、全链路压测。文章来源地址https://www.toymoban.com/news/detail-449017.html

到了这里,关于如何设计一个合格的高并发秒杀系统的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 项目---基于TCP的高并发聊天系统

    目录 服务端  服务端视角下的流程图 一、数据库管理模块 1.1 数据库表的创建 1.2 .对于数据库的操作 1.2.1首先得连接数据库 1.2.2执行数据库语句  1.2.3 返回数据库中存放的所有用户的信息  1.2.4返回数据库中存放的所有用户的好友信息  二、用户管理模块 2.1、UserInfo类:描述

    2023年04月13日
    浏览(51)
  • 七分钟教会你如何编写一个合格的测试用例

    目录 1、测试用例的基本要素 2、根据测试用例去测试带来的好处 3、测试用例的设计方法 3.1、等价类 3.2、边界值 3.3、错误猜测法 3.4、场景法 3.5、因果图法  3.6、正交排列 4、怎样判断一个测试用例是好的测试用例         测试用例是为了实施测试而向被测试的系统提供

    2024年02月03日
    浏览(53)
  • java微服务商城高并发秒杀项目--011.授权规则和系统规则

    授权规则 在shop-order-server中新建RequestOriginParserDefinition.java,定义请求来源如何获取 在shop-order-server中新建AuthController.java,代码如下: 在dashboard中配置白名单和黑名单的相关信息: 设置PC为白名单: 访问测试 访问http://localhost:8091/auth1?serviceName=pc 可以访问 访问http://localhost:8091

    2023年04月16日
    浏览(43)
  • 基于linux下的高并发服务器开发(第一章)- Linux系统IO函数

     (1)man 2 open 打开一个已经存在的文件 int open(const char *pathname, int flags); 参数:             pathname:要打开文件路径             - flags:对文件的操作权限设置还有其他的设置             O_RDONLY,O_WRONLY,O_RDWR 这三个设置是互斥的 返回值:             返回一个新的文件描述

    2024年02月16日
    浏览(60)
  • 设计一个高流量高并发的系统需要关注哪些点

    我相信每一位开发同学多多少少都想参与或负责一个高用户、高访问、高并发的系统吧😁。一来可以增加自己实际的项目经验,有应对高并发场景的解决方案,二来是有个高并发的项目经验无疑是自己简历的一个大大的加分项。但是奈何很多人都没有机会可以参与这样的项目

    2023年04月16日
    浏览(37)
  • 架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路

    目录 大并发/大数据的软件有如下特点 大并发/大数据的架构目标有如下几个 大并发/大数据的设计思路与原则 大并发/大数据的分层架构 1 接入层的架构方案: 第二三层:应用层/服务层架构方案 第四层:数据层架构方案 第五层:基础设施层架构 高并发核武器:单元化+异地

    2024年02月21日
    浏览(51)
  • 高并发系统设计 -- 粉丝关注列表如何设计

    上图我们简称relation页。relation页展示用户的关系相关信息,包含两个子页面: follower页,展示关注该用户的所有用户信息。 attention页,展示该用户关注的所有用户信息 用户可以为自己增加,删除attention,即关注某个其他用户或者对其他用户取消关注。可以删除follower,即取

    2024年02月01日
    浏览(48)
  • 设计一个亿级高并发系统架构 - 12306火车票核心场景DDD领域建模

    “ 架设一个亿级高并发系统,是多数程序员、架构师的工作目标。 许多的技术从业人员甚至有时会降薪去寻找这样的机会。但并不是所有人都有机会主导,甚至参与这样一个系统。今天我们用12306火车票购票这样一个业务场景来做DDD领域建模。” 要实现软件设计、软件开发

    2024年02月03日
    浏览(51)
  • 大秒杀系统设计

    参考链接:http://www.taodudu.cc/news/show-5770725.html?action=onClick 大家还记得2013年的小米秒杀吗?三款小米手机各11万台开卖,走的都是大秒系统,3分钟后成为双十一第一家也是最快破亿的旗舰店。 经过日志统计,前端系统双11峰值有效请求约60w以上的QPS ,而后端cache的集群峰值近

    2024年02月09日
    浏览(37)
  • 用Rust设计一个并发的Web服务:常用Rust库如Tokio、Hyper等,基于TCP/IP协议栈,实现了一个简单的并发Web服务器,并结合具体的代码讲解如何编写并发Web服务器的程序

    作者:禅与计算机程序设计艺术 1994年,互联网泡沫破裂,一批优秀的程序员、工程师纷纷加入到web开发领域。而其中的Rust语言却备受瞩目,它是一种现代系统编程语言,专注于安全和并发。因此,Rust在当下成为最流行的编程语言之一,很多框架也开始使用Rust重构,这使得

    2024年02月06日
    浏览(62)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包