秒杀系统的技术挑战、应对策略以及架构设计总结一二!

参考书籍 | 《大型网站技术架构》 | 李智慧

整理 | 公众号 | Justin谈开发

一、什么是秒杀?

秒杀是电商常见的一种营销手段:将少量的商品,以极低的价格,在特定的时间点开始出售,网站通过这种营销手段,制造某种轰动效应,从而达到网站推广的目的,秒杀虽然对网站推广有很多好处,但是对网站技术却是极大的挑战:网站是为正常运营设计的,而秒杀活动带来的并发访问用户却是平时的数百倍甚至上千倍,网站如果为秒杀时的最大并发访问量去设计部署,就需要比正常运营多很多服务器,而这些服务器在大多数时候都是用不上的,对于成本而言就比较浪费了,所以秒杀业务不能使用正常的网站业务流程,也不能和正常的网站交易业务公用一台服务器,必须设计部署专门的秒杀系统,进行专门应对。

二、秒杀的技术挑战

  • 对现有网站业务造成冲击:秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必然会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪;
  • 高并发下的应用、数据库负载:用户在秒杀活动开始之前,通过不停的刷新浏览器页面以保证不错过秒杀,这些请求如果按照一般网站的应用架构,访问应用服务器,连接数据库,会对应用服务器和数据库服务器造成极大的负载压力;
  • 突然增加的网络及服务器带宽:因为访问秒杀页面的用户剧增,对资源的请求量也是剧增,网络带宽也上去了,超过平时网站使用的带宽;
  • 直接下单:秒杀的规则是到了秒杀秒杀时间才能开始对商品下单购买,在此时间点之前,只能浏览商品信息,不能下单。而下单页面也是一个普通的URL,如果得到了这个URL,不用等到秒杀开始就可以下单了;

三、秒杀系统的应对策略

  • 秒杀系统独立部署:为了避免因为秒杀的高并发访问而拖垮整个网站,使网站不必面对蜂拥而来的用户访问,可将秒杀系统独立部署;如果需要还可以使用独立的域名,使其与网站完全隔离,即使秒杀系统崩溃了,也不会造成网站其他业务正常运行;
  • 秒杀商品页面静态化:重新设计秒杀商品页面,不使用网站原有的商品详情页,页面内容静态化:将商品描述、商品参数、成交记录和用户评价全部写入一个静态页面,用户请求不需要经过应用服务器的业务逻辑处理,也不需要访问数据库,所以秒杀商品服务不需要部署动态的web服务器和数据库服务器;
  • 租借秒杀活动网络带宽:因为秒杀新增的网络带宽,必须和运营商重新购买商品或者租借,为了减轻网站服务器的压力,需要将秒杀商品页面缓存在CDN,同样需要和CDN服务商临时租借新增的流量出口带宽;
  • 动态生成随即下单页面URL:为了避免用户直接访问下单页面URL,需要将该URL动态化,即使秒杀系统的开发者也无法在秒杀之前访问下单页面URL,方案是将下单页面URL加入由服务器端生成的随机数作为参赛,在秒杀开始的时候才能获取得到;

四、秒杀系统架构设计

秒杀系统是为秒杀而设计,不同于一般的网购行为,参与秒杀活动的用户更关心的是如何快速刷新商品页面,在秒杀开始的时候抢先进入下单页面,而不是秒杀商品的详情页用户体验细节,因此秒杀系统页面设计应该尽可能的简单,下单表单也尽可能的简单,购买数量只能是一个且不能修改,送货地址和付款方式都使用用户默认设置的,没有默认也可以先不填,允许等订单提交之后修改;只有第一个提交的订单发送给网站的订单子系统,其余用户提交订单后只能看到秒杀结束的页面,另外还有下面几点需要注意的:

  • 如何控制秒杀商品页面按钮是否可点击:购买按钮在活动开始之前应该要不能点击,当秒杀活动开始才能点击,如果此页面是动态生成的,当然可以在服务器端构造响应页面输出,控制按钮是否可点击,但是为了减轻服务器的负载压力,更好的利用CDN,反向代理等性能优化手段,该页面被设计成静态页面,缓存在CDN、反向代理服务器上,甚至用户浏览器上,秒杀开始时,用户刷新页面,请求根本不会到达应用服务器,解决方案是:使用js脚本控制,在秒杀商品静态页面中加入一个js文件引用,该js文件中加入秒杀是否开始的标志和下单页面URL的随机参数,当秒杀开始时,生成一个新的js文件并被用户浏览器加载,控制秒杀商品页面的展示,这个js文件使用随机版本号,并且不被浏览器、CDN和反向代理服务器缓存,如下图:

这个js文件非常小,即使每次浏览器刷新都访问js文件服务器也不会对服务器集群和网络带宽造成太大的压力。

  • 如何允许第一个提交的订单被发送到订单子系统:假设最终秒杀成功的用户只有一个,那么如何控制呢,在用户提交订单的时候,就得检查是否有订单已经提交,事实上由于最终能够成功提交的用户只有一个,为了减轻下单页面服务器的负载压力,可以控制进入下单页面的入口,只有少数用户能进入下单页面,其他用户直接进入秒杀结束的页面,假设下单服务器集群有10台服务器,每台服务器只接受最多10个请求下单,如下所示:

秒杀整体系统架构如下图:

原文发布于微信公众号 - Java后端技术(JavaITWork)

原文发表时间:2018-03-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Spark学习技巧

HBase高可用集群运维实践

随着越来越多的业务选择HBase作为存储引擎,对HBase的可用性要求也越来越高,对于HBase的运维也提出了新的挑战。目前运维集群超过30+,而且接入的业务类...

49450
来自专栏腾讯NEXT学位

阅读前端项目源码的正确姿势!

19140
来自专栏CSDN技术头条

携程开源Redis多数据中心解决方案XPipe

Redis在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部Redis的读写请求在每秒200W,其中写请求约每秒10W,很多业务甚至会将Redis当成...

48890
来自专栏

基于JMS的数据交换既数据互操作平台的解决方案

为解决应用系统间数据和信息的互通、互用,建立一个通用的、分布式的数据集成平台,用以解决异构数据平台数据交流和沟通的问题。

65740
来自专栏架构师之路

小小的IP,大大的耦合,你痛过吗?

什么是耦合? 耦合,是架构中,本来不相干的代码、模块、服务、系统因为某些原因联系在一起,各自独立性差,影响则相互影响,变动则相互变动的一种架构状态。 感官上,...

48460
来自专栏猿人谷

三种Linux服务器监控技术的对比

本文介绍三种Linux服务器监控技术的优缺点,其中有SNMP代理(客户端)方式、SSH方式、安装私有代理(客户端)方式等内容。 Linux系统的强大的功能和绚丽...

26170
来自专栏hotqin888的专栏

MeritMS与Bentley Project Wise对比校审流程

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/hotqin888/article/det...

22210
来自专栏姬小光

科普 | 移动端应用相互跳转的 16 种路径详解

移动时代,我们手机里的东西越来越多,占用的时间也越来越多。有时候要用 APP,有时候要在微信里跳来跳去,有时候又要打开浏览器,每天忙得不亦乐乎。

17610
来自专栏子勰随笔

SDK开发经验之文档

25780
来自专栏小巫技术博客

App更新策略课程完结篇

14230

扫码关注云+社区

领取腾讯云代金券