李智慧 · 高并发架构实战课
李智慧
同程艺龙交通首席架构师,前 Intel & 阿里架构师,《大型网站技术架构》作者
23286 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 26 讲
李智慧 · 高并发架构实战课
15
15
1.0x
00:00/00:00
登录|注册

08 | 秒杀系统设计:你的系统可以应对万人抢购盛况吗?

计数器限制并发请求
服务器本地缓存
CDN缓存
浏览器缓存
控制按钮状态和下单URL
动态生成JavaScript文件
限流处理
使用缓存降低负载
控制购买按钮状态
简化页面元素
对于大量用户购买大量商品的场景(如双十一)的设计思路
架构师的技术与勇气
秒杀系统设计的实际案例分析
全局计数器管理订单创建
限流器控制下单请求
特殊JavaScript文件控制秒杀逻辑
用户通过CDN或缓存访问商品页面
秒杀商品页面购买按钮点亮方案设计与下单URL下发
秒杀系统的流量控制
独立秒杀系统页面设计
防止跳过秒杀页面直接下单
独立开发部署秒杀系统
保证秒杀活动的公平性
应对高并发访问压力
思考题
小结
秒杀系统部署模型
概要设计
需求分析
核心挑战
秒杀系统设计

该思维导图由 AI 生成,仅供参考

你好,我是李智慧。
秒杀是电子商务应用常见的一种营销手段:将少量商品(常常只有一件)以极低的价格,在特定的时间点出售。比如,周日晚上 8 点整,开售 1 部 1 元钱的手机。 因为商品价格诱人,而且数量有限,所以用户趋之若鹜,在秒杀活动开始前涌入系统, 等到秒杀活动开始的一瞬间,点下购买按钮(在此之前购买按钮为灰色,不可以点击),抢购商品。
秒杀虽然对应用推广有很多好处,但是对系统技术却是极大的挑战:系统是为正常运营设计的,而秒杀活动带来的并发访问用户却是平时的数百倍甚至上千倍。也就是说,秒杀的时候,系统需要承受比平时多得多的负载压力。
为了应对这种比较特殊的营销活动,我们启动了一个专门的秒杀项目,项目代号是“Apollo”。Apollo 的核心挑战是:如何应对突然出现的数百倍高并发访问压力,并保证用户只有在秒杀开始时才能下单购买秒杀商品?接下来我们就看看 Apollo 的需求与技术架构吧。

需求分析

Apollo 的需求主要有两点。
独立开发部署秒杀系统,避免影响现有系统和业务
秒杀活动只是网站营销的一个附加活动,这个活动具有时间短、瞬间并发访问量大的特点,如果和网站原有应用部署在一起,必然会对现有业务造成冲击,稍有不慎可能导致整个系统瘫痪。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

秒杀系统设计是电子商务应用中常见的一种营销手段,但对系统技术提出了极大的挑战。本文介绍了一个名为“Apollo”的秒杀项目,旨在解决系统如何应对突然出现的数百倍高并发访问压力,并保证用户只有在秒杀开始时才能下单购买秒杀商品的核心挑战。为了满足这一需求,文章提出了独立开发部署秒杀系统、防止跳过秒杀页面直接下单等需求,并详细讨论了秒杀系统的页面设计、流量控制以及购买按钮点亮方案设计与下单URL下发。其中,文章强调了使用多级缓存方案和限流处理来降低服务器的负载压力,并介绍了如何在秒杀商品静态页面中加入特殊的JavaScript文件来控制秒杀按钮的点亮和提交表单的URL参数。这些设计方案可以有效应对绝大多数情况下秒杀带来的高并发压力,为系统设计提供了有益的参考。 文章还提到了一个真实案例,描述了一个架构师在短时间内成功完成了一个大规模的秒杀活动,从而获得了公司内的认可和晋升。这个案例强调了在关键时刻有勇气面对挑战的重要性,以及技术在建立自信和解决问题时的作用。 总的来说,本文通过介绍“Apollo”秒杀系统的设计思路和技术实现,以及真实案例的启示,为读者提供了对应对高并发访问压力的系统设计和挑战的深入了解,同时也激励读者在关键时刻勇敢面对挑战,建立自信,克服困难。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《李智慧 · 高并发架构实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(21)

  • 最新
  • 精选
  • 👽
    首先,我个人分析: 大促跟秒杀系统最大的不同在于——秒杀大部份下单请求是被拒绝的。而双十一这种活动,是尽可能将所有请求都受理。否则就会出现损失。 持续时长一般比秒杀业务长,秒杀的高并发可能是几分钟内的,而大促活动,可能持续几小时。 并发数预测大幅度小于秒杀。 基于以上的前提设计系统。 首先,基础架构方面。大促持续时长虽然高于秒杀。但是仍然并非常态。所以,计算资源应该是支持弹性伸缩的。应对大促时,增加服务副本数量,平时将资源释放。 cdn 静态资源缓存的设计可以沿用。 网关层面,根据源IP或者用户控制请求频率。还是之前的问题,秒杀,你可以把处理不了的请求直接拒绝掉,但是大促情况下不可以。损失一个订单,就是一笔收益。所以根据ip或者用户,进行限流。 为了节约短时间内的高并发请求,也可以尝试引入消息队列中间间,将部分请求先受理,排队处理,服务器空闲时候再处理这些业务。 总结一下的话,核心就是:弹性伸缩,资源预留;用户限流,限制请求;短时间高并发,MQ削峰填谷;

    作者回复: 非常赞,思路很完整

    2022-03-05
    3
    27
  • Steven
    双十一这种电商大促场景,不同于秒杀场景,需要尽可能多的满足下单支付需求。 虚拟化技术,容器技术来进行弹性伸缩,大促阶段增加资源,大促结束了释放。 限流、熔断、降级等手段,以保证核心业务的可用性。 MQ用来消峰填谷。 多级缓存,尤其静态资源在CDN要大规模使用。 另,非技术方面,比如: 引导用户提前把要买的物品添加购物车,可以预估流量。 个别商品、商家提前进入大促,也可以分流压力。

    作者回复: 赞

    2022-03-09
    11
  • Rick
    请问一下为什么要使用动态生成js文件的方式来控制按钮点亮。为什么不直接使用http api请求直接从服务器端动态获取控制参数{是否开始秒杀了,提交请求的随机数等}。

    作者回复: 这个设计的场景主要是针对Web浏览器。App上的话api控制更好。

    2022-03-05
    9
  • 华佗救不了你
    用来下发特殊js的那个接口,虽然占带宽不会高,但是QPS必然很高。而且还随着URL下发了一个随机数,显然这个请求不能简单地走缓存。即使可以走缓存,针对大流量是不是依旧需要部署大量的机器? 老师可以说详细点这个点吗?

    作者回复: 是的,不能走缓存。 js的响应时间是毫秒,单服务器QPS可以支持几万,完全可以承受。

    2022-03-10
    6
  • neohope
    电商大促场景: 0、尽早做好各相关团队的沟通,做好活动动员工作 1、业务上分时段大促,不同商品分流,缓解服务器甚至快递小哥压力 2、做好静态资源缓存:浏览器、CDN、服务器缓存 3、根据过往流量、商品浏览量、购物车商品数量,估算大促流量 4、做好扩容和运维保障工作:服务器、带宽、数据库根据预测流量,进行弹性扩容,而且要有一定比例的富余量 5、大促商品信息提前加载redis缓存 6、引入MQ,异步处理订单,消除业务峰值 7、做好PlanB,限流、降级、熔断,保证核心业务稳定 8、网关控制同IP流量,屏蔽部分服务器IP断,防止部分刷单行为 9、提前做好性能测试及压力测试

    作者回复: 赞

    2022-04-29
    4
  • 喆里
    有个问题详请教下,客户端怎么知道秒杀活动什么时候开始? (两边的时间可能不一致) 因此,是不是客户端每次刷新,还是会请求到js服务器,秒杀没开始时,响应是空白js;秒杀开始后,返回是真正有用的js ?

    作者回复: 是的

    2022-06-15
    3
  • 子路
    秒杀更多思考是如何处理请求,库存很少,所以99%的请求都可以被抛弃,甚至它们都请求不到服务器,在网关或者负载阶段就被拒绝了,所以秒杀的服务器并没有承载的压力!

    作者回复: 是的

    2022-04-26
    2
  • Geek_edffd3
    1.这里url动态化使用接口获取而不是通过js同步更简单? 2.url动态化到底能起到多大作用呢?获取url可以通过脚本刷接口获得,可以更快地感知到活动开始和获取到url,也就意味着可以更早的去下单。所以,它真正起到了什么作用呢? 3.其实,不动态url,可以钓鱼,如果活动开始前调用接口就可以直接拉入黑名单。 4.关于按钮置灰,直接前端简单做个效果就好了,对于一般用户就是灰的,对于非一般用户,接口里面肯定会检验活动开始时间的,没开始也不可能成功的。 老师,希望得到你的答疑解惑,谢谢🙏

    作者回复: 1 这个设计主要针对web浏览器场景的,只能JS 2 有随机数,动态化主要目的是防止秒杀开始前下单。 3 人也会调接口的,直接黑名单有点太粗暴。可以用类似区块链那种hash碰撞,要求客户端必须进行一个复杂的CPU计算才能请求后端,可以降低脚本机器人的的优势。

    2022-04-21
    2
  • 1angxi
    19年的时候搞过秒杀,因此场次比较少,所以不需要考虑anti fraud。用了单机限流只让极少流量进入下单逻辑。这里没怎么讲库存扣减的逻辑,这也是一块比较核心的技术点,秒杀超卖是绝对不能接受的。

    作者回复: 秒杀最后进入正常的下单流程,下单流程包含了库存扣减。 极少的流量进入下单逻辑,这个时候已经跟秒杀没关系了。

    2022-03-28
    2
  • HappyHasson
    这里会有一个风险点吧。 定时服务器在生成js脚本和随机值的时刻,想JavaScript服务器集群推消息,如果这时候某一台服务器网络有问题,没收到推送的消息,导致连到这台服务器的用户都看不到活动开始,等看到的时候已经结束了,这种情况玩家体验会很差吧。 是否可以在JavaScript服务集群实例上自己起定时器,生成随机值给到client。随机种子一致,结果一致即可。

    作者回复: 嗯,你说的风险确实存在。这个风险可以通过一些高可用的运维手段来降低,但是风险还是会存在的。 你的建议会带来另一个问题,这个随机种子谁来设定?如果这个种子被泄漏,有人在秒杀开始前生成随机值,抢了商品怎么办?如果秒杀的商品价值比较高,会涉及刑事调查,你作为架构师能承担这个责任吗?

    2022-03-19
    2
    2
收起评论
显示
设置
留言
21
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部