08 | 秒杀系统设计:你的系统可以应对万人抢购盛况吗?
该思维导图由 AI 生成,仅供参考
需求分析
- 深入了解
- 翻译
- 解释
- 总结
秒杀系统设计是电子商务应用中常见的一种营销手段,但对系统技术提出了极大的挑战。本文介绍了一个名为“Apollo”的秒杀项目,旨在解决系统如何应对突然出现的数百倍高并发访问压力,并保证用户只有在秒杀开始时才能下单购买秒杀商品的核心挑战。为了满足这一需求,文章提出了独立开发部署秒杀系统、防止跳过秒杀页面直接下单等需求,并详细讨论了秒杀系统的页面设计、流量控制以及购买按钮点亮方案设计与下单URL下发。其中,文章强调了使用多级缓存方案和限流处理来降低服务器的负载压力,并介绍了如何在秒杀商品静态页面中加入特殊的JavaScript文件来控制秒杀按钮的点亮和提交表单的URL参数。这些设计方案可以有效应对绝大多数情况下秒杀带来的高并发压力,为系统设计提供了有益的参考。 文章还提到了一个真实案例,描述了一个架构师在短时间内成功完成了一个大规模的秒杀活动,从而获得了公司内的认可和晋升。这个案例强调了在关键时刻有勇气面对挑战的重要性,以及技术在建立自信和解决问题时的作用。 总的来说,本文通过介绍“Apollo”秒杀系统的设计思路和技术实现,以及真实案例的启示,为读者提供了对应对高并发访问压力的系统设计和挑战的深入了解,同时也激励读者在关键时刻勇敢面对挑战,建立自信,克服困难。
《李智慧 · 高并发架构实战课》,新⼈⾸单¥59
全部留言(21)
- 最新
- 精选
- 👽首先,我个人分析: 大促跟秒杀系统最大的不同在于——秒杀大部份下单请求是被拒绝的。而双十一这种活动,是尽可能将所有请求都受理。否则就会出现损失。 持续时长一般比秒杀业务长,秒杀的高并发可能是几分钟内的,而大促活动,可能持续几小时。 并发数预测大幅度小于秒杀。 基于以上的前提设计系统。 首先,基础架构方面。大促持续时长虽然高于秒杀。但是仍然并非常态。所以,计算资源应该是支持弹性伸缩的。应对大促时,增加服务副本数量,平时将资源释放。 cdn 静态资源缓存的设计可以沿用。 网关层面,根据源IP或者用户控制请求频率。还是之前的问题,秒杀,你可以把处理不了的请求直接拒绝掉,但是大促情况下不可以。损失一个订单,就是一笔收益。所以根据ip或者用户,进行限流。 为了节约短时间内的高并发请求,也可以尝试引入消息队列中间间,将部分请求先受理,排队处理,服务器空闲时候再处理这些业务。 总结一下的话,核心就是:弹性伸缩,资源预留;用户限流,限制请求;短时间高并发,MQ削峰填谷;
作者回复: 非常赞,思路很完整
2022-03-05327 - Steven双十一这种电商大促场景,不同于秒杀场景,需要尽可能多的满足下单支付需求。 虚拟化技术,容器技术来进行弹性伸缩,大促阶段增加资源,大促结束了释放。 限流、熔断、降级等手段,以保证核心业务的可用性。 MQ用来消峰填谷。 多级缓存,尤其静态资源在CDN要大规模使用。 另,非技术方面,比如: 引导用户提前把要买的物品添加购物车,可以预估流量。 个别商品、商家提前进入大促,也可以分流压力。
作者回复: 赞
2022-03-0911 - Rick请问一下为什么要使用动态生成js文件的方式来控制按钮点亮。为什么不直接使用http api请求直接从服务器端动态获取控制参数{是否开始秒杀了,提交请求的随机数等}。
作者回复: 这个设计的场景主要是针对Web浏览器。App上的话api控制更好。
2022-03-059 - 华佗救不了你用来下发特殊js的那个接口,虽然占带宽不会高,但是QPS必然很高。而且还随着URL下发了一个随机数,显然这个请求不能简单地走缓存。即使可以走缓存,针对大流量是不是依旧需要部署大量的机器? 老师可以说详细点这个点吗?
作者回复: 是的,不能走缓存。 js的响应时间是毫秒,单服务器QPS可以支持几万,完全可以承受。
2022-03-106 - neohope电商大促场景: 0、尽早做好各相关团队的沟通,做好活动动员工作 1、业务上分时段大促,不同商品分流,缓解服务器甚至快递小哥压力 2、做好静态资源缓存:浏览器、CDN、服务器缓存 3、根据过往流量、商品浏览量、购物车商品数量,估算大促流量 4、做好扩容和运维保障工作:服务器、带宽、数据库根据预测流量,进行弹性扩容,而且要有一定比例的富余量 5、大促商品信息提前加载redis缓存 6、引入MQ,异步处理订单,消除业务峰值 7、做好PlanB,限流、降级、熔断,保证核心业务稳定 8、网关控制同IP流量,屏蔽部分服务器IP断,防止部分刷单行为 9、提前做好性能测试及压力测试
作者回复: 赞
2022-04-294 - 喆里有个问题详请教下,客户端怎么知道秒杀活动什么时候开始? (两边的时间可能不一致) 因此,是不是客户端每次刷新,还是会请求到js服务器,秒杀没开始时,响应是空白js;秒杀开始后,返回是真正有用的js ?
作者回复: 是的
2022-06-153 - 子路秒杀更多思考是如何处理请求,库存很少,所以99%的请求都可以被抛弃,甚至它们都请求不到服务器,在网关或者负载阶段就被拒绝了,所以秒杀的服务器并没有承载的压力!
作者回复: 是的
2022-04-262 - Geek_edffd31.这里url动态化使用接口获取而不是通过js同步更简单? 2.url动态化到底能起到多大作用呢?获取url可以通过脚本刷接口获得,可以更快地感知到活动开始和获取到url,也就意味着可以更早的去下单。所以,它真正起到了什么作用呢? 3.其实,不动态url,可以钓鱼,如果活动开始前调用接口就可以直接拉入黑名单。 4.关于按钮置灰,直接前端简单做个效果就好了,对于一般用户就是灰的,对于非一般用户,接口里面肯定会检验活动开始时间的,没开始也不可能成功的。 老师,希望得到你的答疑解惑,谢谢🙏
作者回复: 1 这个设计主要针对web浏览器场景的,只能JS 2 有随机数,动态化主要目的是防止秒杀开始前下单。 3 人也会调接口的,直接黑名单有点太粗暴。可以用类似区块链那种hash碰撞,要求客户端必须进行一个复杂的CPU计算才能请求后端,可以降低脚本机器人的的优势。
2022-04-212 - 1angxi19年的时候搞过秒杀,因此场次比较少,所以不需要考虑anti fraud。用了单机限流只让极少流量进入下单逻辑。这里没怎么讲库存扣减的逻辑,这也是一块比较核心的技术点,秒杀超卖是绝对不能接受的。
作者回复: 秒杀最后进入正常的下单流程,下单流程包含了库存扣减。 极少的流量进入下单逻辑,这个时候已经跟秒杀没关系了。
2022-03-282 - HappyHasson这里会有一个风险点吧。 定时服务器在生成js脚本和随机值的时刻,想JavaScript服务器集群推消息,如果这时候某一台服务器网络有问题,没收到推送的消息,导致连到这台服务器的用户都看不到活动开始,等看到的时候已经结束了,这种情况玩家体验会很差吧。 是否可以在JavaScript服务集群实例上自己起定时器,生成随机值给到client。随机种子一致,结果一致即可。
作者回复: 嗯,你说的风险确实存在。这个风险可以通过一些高可用的运维手段来降低,但是风险还是会存在的。 你的建议会带来另一个问题,这个随机种子谁来设定?如果这个种子被泄漏,有人在秒杀开始前生成随机值,抢了商品怎么办?如果秒杀的商品价值比较高,会涉及刑事调查,你作为架构师能承担这个责任吗?
2022-03-1922