第一章 出师不利
截止到13年12月初,VMALL已支撑过很多轮的活动了,包括荣耀2,P6,Mate等著名产品,所有的活动都未有超过荣耀四核的流量与压力,太久没有大战了,现在大战来了,荣耀3C突然要搞活动了,说实话,对其能达到什么程度,是没有概念的,因此一场未能提前充份准备的战斗就这样不期而至了。
一、风云突变
VMALL的故事,更久的源头就远了,还是将镜头拉到2013年12月17日,荣耀3C一天预约近百万,远远超出我们的预期,在荣耀四核首次搞这种抢购活动,在预约赢smart车的刺激之下,在QQ全力引流之下,三天预约了80多万,那曾是个顶峰,在一年多的时间内,我们就未曾再达到过如此高度。此前和营销、市场就流量进行多次沟通,大家的意见都统一认为按P6流量准备方案与资源。
面对突然的变局,当天召集骨干进行紧急会议,首先对预约用户进行了分析,其中有大量用户帐号是虚假Email,有很多是机器预约的。从其他部门也得到信息,小米在荣耀3C发布会当晚,召集各路水军、大V研讨对策。
问题1:对手可能出什么招?
问题2:我们需要进行怎样的防范?
这是我们当天必须要尽快明确下来的问题,一周之后,就是正式抢购。
对于问题1,我们都很纠结,这是明和暗的斗争,我们身在明处,对手在暗处,看不见但无处不在。用机器手段预约这么多用户,目的何为? 从人性角度出发,动机在哪儿? 既无名,也无利。
如果说对手买通,也难以说通,这样造成更多预约用户,完全是正面宣传。
会在抢购期干些什么?
如果都被他们抢了,别人抢不到,那造成更为饥渴状态,也是正面宣传。如果故意黑死网站,除了对当期销售有负面影响,对商品角度,也一样会造成更为紧俏的正面影响。且首发的是多个平台,有经历大风大浪的京东,也不是那么容易被黑死,估计对手也不敢啊。
再换位一下,假如我们是小米,我们会去帮助宣传荣耀3C吗?即使是负面宣传,都不合适,容易利用自己很强的互联网影响力,帮助了对手。如果我们是小米,最好应该是不让荣耀3C与小米任何产品产生关联。
为了求证,我们立即到小米论坛去找相关荣耀3C信息,确实从侧面证明这样海量的机器预约行为,应该不是对手所为。在小米论坛中,在当时,没有任何一条荣耀3C相关信息。我们当时就很佩服小米的运营管理,那可是远比我们论坛大得多的人群,能管住声音,是很用心,也很有执行力的。
回到我们自身,当时给出的判断这些大量无效用户,是由恶意的人制造,先做准备,再进行攻击前准备。
结论:大量是无效的用户(虚假Email帐号),有效用户规模虽然仍会超过荣耀四核,但超过的不多。正常用户的抢购压力应与荣耀四核相当,但面临恶意攻击的风险很高。
这个判断,现在回头去看自然是错的,但再回到当时,以我们当时的水平、经验以及掌握的信息,让我们判断不清。这个判断的错误,给我们带来的后果是非常严重的。
时间留给我们的只有一周,抢购既定的方案,是从荣耀四核抢购方案逐步演进过来的,经历过很多轮的抢购活动了,但我们知道,面临的是新问题,新风险。
基于问题1的判断,我们开始了问题2的讨论,主站可能的入口太多了,受攻击的点太多了,一个一个分析软肋已没有这个时间,当时大家紧张讨论,最后明确了几点:
1. 紧急扩容服务器,用来增加扛攻击能力,同时,用于应急预案设备。
2. 带宽已无增加可能,再扩容需运营商施工,这个周期已不可能。
3. 最坏的情况下,保住活动,三级有损服务,最低级情况,记录抢购用户,进行后处理。
4. 真要是DDOS攻击,以我们的带宽及服务器资源,除了认命,挂免战牌,没什么招了。
我们的方案:
主 案
采用既有抢购流程,完成正常商品抢购、下单。 基于历史数据,可承载在线并发用户20万。
预案 1
在活动开始前,如果并发用户超20万,或者主站访问拥塞,启动本案.
流量由LVS切换到NGX分发服务器集群,利用NGX的分发策略,对后端服务分两组,确保组与可损组。确保组有两类服务,纯静态部分由另一组NGX服务集群构成,用于提供静态页面服务;动态部分只有写临时订单文件服务(不写DB)的集群,该集群由Apache+Tomcat组成,Apache提供基础性过负荷能力,控制向Tomcat的连接请求量。NGX首次使用,性能没有测试,在网络上有介绍,性能很高。对于可损组,实际是主站原有系统部分,如用户鉴权等。
预案 2
在预案1的基础之上,若出现用户数很少,无法登录,或无法获取用户登录态相关信息,则更换预案1中的静态文件,收集用户的手机号码、用户收货地址信息,记录文件,后处理再生成订单。
方案上报各相关部门备案,开始紧张的方案实现工作!
二、山雨欲来
12.25日凌晨3:00,叫来夜宵,大家边补充能量边讨论可能存在的问题。我们的预言帝叹口气,预案准备太不充分了。是的,一周时间,准备太仓促,使用的NGINX还是我们从未实战过的新系统,我们最后的底牌能否管用,不知道。
12.25日凌晨5:00,预案总算功能测试通过,显然,我们已无时间进行性能测试了,赶紧进行现网部署、验证。
12.25日凌晨6:30,所有环境部署完成,各业务流程都在现网跑通。
12.25日上午7:00,大家买了早点,吃完。让大家小憩一下。
12.25日上午7:00~8:00,寂静!暴风雨前兆!独自坐在会议室,面对乱麻一样的白板上各种讨论,最后再全面整理着思绪。敌人会从哪儿攻击?
12.25日上午,8:00~9:00,各单位陆续就岗,作战室开始工作。已登录用户5万,暂时未见系统异常。
12.25日上午,9:00~9:30, 流量激增一倍,用户登录10万,预期用户肯定会超过20万,作战室,启动预警。
三、狂风暴雨
12.25日上午,9:30~9:40,新增2.5万用户,主站系统开始感受到压力,页面响应开始有些变慢,仍在可接受范围。
12.25日上午,9:40~9:50,新增4万多用户,系统压力明显增加,网络负载很重,有部分系统开始告警。该关闭的服务,立即关闭。
12.25日上午,9:50~10:00,新增7万多用户。已越过警戒线!系统已产生大量告警,网站访问已出现较重卡顿。作战室内紧急讨论,先启动预案试试!
于是,试着开启了预案设备,然而,惊讶地发现,切换了不到几秒钟,预案设备全部宕机!又手工启动一次,结果一样!冲击力之强,完全超出了我们的想象!
12.25日上午,10:00~10:05,5分钟里又激增6万多用户,已超过30万用户堵在抢购门口了!现在预案设备出问题,原因来不及排查,只有3分钟就开始抢购了!我们在作战室内看着激增的流量,拥塞的网站,大量系统告警,空气都凝结了。只能孤注一掷,就用之前老方案去扛了!
12.25日上午,10:05~10:08, 在各种卡堵之下,还是又新增了6万用户,差不多40万登录用户堵在门口,还有一群未能完成登录的堵在各条路上,网络带宽达到极限。到点了,开闸!
四、一叶扁舟
如果用什么来形容当时的心情,立即闪在我脑海中的,就是《完美风暴》中船长Billy Tyne最后决定,掉转船头,直向风暴中心!最后船撞在如山的浪墙之上,失速沉没!
可怜的活动抢购系统,确如在茫茫大海之中,孤独面对狂暴风雨的一叶扁舟,随时会被巨浪吞没!
开闸之后,我们紧张地盯着订单,时间一秒一秒地过,每一秒都象是一记重锤敲击在心头,心中默算着,普通用户下完订单的时间。
10秒!首个订单出来了!
耶!大家都紧握拳头!活着!我们的小船还没沉没!虽然艰难,但顽强地活着!
网络带宽处于高位,很多子系统出现异常,不能响应请求,最不可理喻的,是大量异常与告警,但服务器CPU并没耗完。
拥挤!拥挤!还是拥挤!
但活动子系统,还坚强地活着,它的性能无法达到预期的能力,在前面很多环节的拥塞,会让很多人不能顺利地完成下单,尤其很多人会去重新刷页面,实际基本就更没机会。订单每秒都在增长,没有期望的快,但在稳中有升,在逐步提升下单速度中。
有些服务器始终可以正常工作,有些服务器就是不能正常工作,内部局域网有异常丢包!
五、风暴退去
10:16分,活动结束!
10:30分,活动结束十几分钟了,压力仍然巨大,又新增十几万用户!
12:00,用户达到60万人,中午时分,压力开始因饥饿而缓解,人总是要吃饭的。系统访问总算恢复正常。
下午,主要骨干休息,后备组收集各系统日志!将原关停服务逐步恢复!
第二章、快速反击
输得体无完肤,还能不能再战?敢不敢再战?
示弱!但不怯战!
拿着小学算术(见后),与各周边协商讨论方案,提出降低部分体验,如页面精美度需要牺牲,用户购物要分段完成等,最重要的,主站在活动期间隐身示弱!最终方案获得认可,全力以战!
六、输无可输
12.25日 19:00,作战室几个骨干一起坐下开会讨论。
气氛很压抑沉闷,大家已很疲惫,但结果很差,历来新品首发,总是VMALL超过其他平台,今天未达预期,系统被拥挤得不行,在心声上也被痛骂,大家都深感惭愧。
会议开始的几分钟,大家都在沉默,看着大家的神态,我也重新整理着头绪。
首先,我们必须接受这个事实,我们的方案没有经受住考验。
至于原因,我们还需要花相当的精力去追查,但显然也不是几天时间能查透彻的,各系统日志都是海量的,要分析出根本原因,核心环节,是要花费不少时间的,而下次面对的问题可能不同,而下次就是12.31日的二轮抢购,留给我们的时间只有5天!因此,我们先保留现场,保留各类错误日志,待进一步分析。
毫无疑问,我们现在最重要的是重拾心情与信心,要打一场快速反击战!
其次,我们退无可退,31日二轮抢购,压力不会降低,可能更高。正如前面的分析,系统拥塞,会被动地成为3C热度上升的助力器。再加上,二轮产量远远超过首轮,必须要趁热大量出货。系统如果再瘫,那就没有然后了。
基本问题点:
1. 预案失效。 NGX分发集群,完全未能扛住流量。 预案设备中,出现大量内网丢包,必须要查明。这让我们死得不明不白。
2. 不符合预期的动态请求量。首页、3C详情页都是静态化的,按理用户应主要访问的就是这两个静态页面。为什么会有大量动态访问?为什么不符合设想的模型?
3. 看不见的瓶颈。有些服务器坚强,有些服务器脆弱,很多服务器并没看到性能达到瓶颈,为什么。这和测试模式差异很大。
(这些问题,我们联合企业云一起,在二轮抢购(12.31日)活动之后,结合31日现场数据观测,参数调整,最后给出相应的分析。有两个底层的问题,一个是云平台组网方案中依赖iptables的安全策略,VMALL的分组、分域的网络安全策略较为复杂,iptables性能出现瓶颈,这在31日现场观测中被印证,通过临时调高参数规避;另外,VMALL的虚机数量庞大,虚拟机在物理机上分布有问题,面对这种同时达峰值的压力,多台虚机在同一物理机上,造成物理机瓶颈。)
应对31日的方案要点:
1. 紧急请求企业云支持,紧急增加设备;
2. 紧急请求企业云支持,将出口带宽扩大一倍,将主、备两路变为双主来紧急应对;
3. 紧急申请一批服务器,独立构建活动系统,并要求分散虚拟机(虽未分析出原因,但感觉虚机分布可能有问题);
4. 其他业务机房紧急申请一批服务器,作为节流阀之用,进行流量调控;
5. 暂停冒险使用NGX作法,仍采用多组LVS,应用层采用已成熟使用的Apache+Tomcat技术;
6. 主站系统过于复杂,软肋很多,在完成主站优化改造前,先示弱,抢购期主站隐身,全站只提供抢购服务,其他服务停止;
7. 抢购活动先做减法,将复杂逻辑去除,牺牲局部体验,保证全局体验,功能简化到极致;
8. 静态与动态隔离,静态部分用服务器数量去扛,为保障带宽,所有页面元素精简,控制页面大小;提示禁止刷屏,页面截获F5;采用本机时间,避免上行压力;
9. 页面各部分大小要求:全部图片大小不得超过50K;各JS+HTML等大小累计不得超过20K;上行请求不得超过2K;(可参见后面的小学算术)
10. 抢购活动,只干一件事,到时间点,用户一个点击即上报用户信息,服务端按时间排序。服务端分多组完全独立,各自平均配额,用完即止。
11. 抢购配额全部用完,就活动停止。活动停止后,进行后处理,将合法排队用户以提交时间为序生成订单。
12. 所有订单生成后,按区域放开主站,让用户完成订单地址填写并完成支付。
最大的风险,估计就在于主站开放,初步评估后处理需要半小时。
截止到13年12月初,VMALL已支撑过很多轮的活动了,包括荣耀2,P6,Mate等著名产品,所有的活动都未有超过荣耀四核的流量与压力,太久没有大战了,现在大战来了,荣耀3C突然要搞活动了,说实话,对其能达到什么程度,是没有概念的,因此一场未能提前充份准备的战斗就这样不期而至了。
一、风云突变
VMALL的故事,更久的源头就远了,还是将镜头拉到2013年12月17日,荣耀3C一天预约近百万,远远超出我们的预期,在荣耀四核首次搞这种抢购活动,在预约赢smart车的刺激之下,在QQ全力引流之下,三天预约了80多万,那曾是个顶峰,在一年多的时间内,我们就未曾再达到过如此高度。此前和营销、市场就流量进行多次沟通,大家的意见都统一认为按P6流量准备方案与资源。
面对突然的变局,当天召集骨干进行紧急会议,首先对预约用户进行了分析,其中有大量用户帐号是虚假Email,有很多是机器预约的。从其他部门也得到信息,小米在荣耀3C发布会当晚,召集各路水军、大V研讨对策。
问题1:对手可能出什么招?
问题2:我们需要进行怎样的防范?
这是我们当天必须要尽快明确下来的问题,一周之后,就是正式抢购。
对于问题1,我们都很纠结,这是明和暗的斗争,我们身在明处,对手在暗处,看不见但无处不在。用机器手段预约这么多用户,目的何为? 从人性角度出发,动机在哪儿? 既无名,也无利。
如果说对手买通,也难以说通,这样造成更多预约用户,完全是正面宣传。
会在抢购期干些什么?
如果都被他们抢了,别人抢不到,那造成更为饥渴状态,也是正面宣传。如果故意黑死网站,除了对当期销售有负面影响,对商品角度,也一样会造成更为紧俏的正面影响。且首发的是多个平台,有经历大风大浪的京东,也不是那么容易被黑死,估计对手也不敢啊。
再换位一下,假如我们是小米,我们会去帮助宣传荣耀3C吗?即使是负面宣传,都不合适,容易利用自己很强的互联网影响力,帮助了对手。如果我们是小米,最好应该是不让荣耀3C与小米任何产品产生关联。
为了求证,我们立即到小米论坛去找相关荣耀3C信息,确实从侧面证明这样海量的机器预约行为,应该不是对手所为。在小米论坛中,在当时,没有任何一条荣耀3C相关信息。我们当时就很佩服小米的运营管理,那可是远比我们论坛大得多的人群,能管住声音,是很用心,也很有执行力的。
回到我们自身,当时给出的判断这些大量无效用户,是由恶意的人制造,先做准备,再进行攻击前准备。
结论:大量是无效的用户(虚假Email帐号),有效用户规模虽然仍会超过荣耀四核,但超过的不多。正常用户的抢购压力应与荣耀四核相当,但面临恶意攻击的风险很高。
这个判断,现在回头去看自然是错的,但再回到当时,以我们当时的水平、经验以及掌握的信息,让我们判断不清。这个判断的错误,给我们带来的后果是非常严重的。
时间留给我们的只有一周,抢购既定的方案,是从荣耀四核抢购方案逐步演进过来的,经历过很多轮的抢购活动了,但我们知道,面临的是新问题,新风险。
基于问题1的判断,我们开始了问题2的讨论,主站可能的入口太多了,受攻击的点太多了,一个一个分析软肋已没有这个时间,当时大家紧张讨论,最后明确了几点:
1. 紧急扩容服务器,用来增加扛攻击能力,同时,用于应急预案设备。
2. 带宽已无增加可能,再扩容需运营商施工,这个周期已不可能。
3. 最坏的情况下,保住活动,三级有损服务,最低级情况,记录抢购用户,进行后处理。
4. 真要是DDOS攻击,以我们的带宽及服务器资源,除了认命,挂免战牌,没什么招了。
我们的方案:
主 案
采用既有抢购流程,完成正常商品抢购、下单。 基于历史数据,可承载在线并发用户20万。
预案 1
在活动开始前,如果并发用户超20万,或者主站访问拥塞,启动本案.
流量由LVS切换到NGX分发服务器集群,利用NGX的分发策略,对后端服务分两组,确保组与可损组。确保组有两类服务,纯静态部分由另一组NGX服务集群构成,用于提供静态页面服务;动态部分只有写临时订单文件服务(不写DB)的集群,该集群由Apache+Tomcat组成,Apache提供基础性过负荷能力,控制向Tomcat的连接请求量。NGX首次使用,性能没有测试,在网络上有介绍,性能很高。对于可损组,实际是主站原有系统部分,如用户鉴权等。
预案 2
在预案1的基础之上,若出现用户数很少,无法登录,或无法获取用户登录态相关信息,则更换预案1中的静态文件,收集用户的手机号码、用户收货地址信息,记录文件,后处理再生成订单。
方案上报各相关部门备案,开始紧张的方案实现工作!
二、山雨欲来
12.25日凌晨3:00,叫来夜宵,大家边补充能量边讨论可能存在的问题。我们的预言帝叹口气,预案准备太不充分了。是的,一周时间,准备太仓促,使用的NGINX还是我们从未实战过的新系统,我们最后的底牌能否管用,不知道。
12.25日凌晨5:00,预案总算功能测试通过,显然,我们已无时间进行性能测试了,赶紧进行现网部署、验证。
12.25日凌晨6:30,所有环境部署完成,各业务流程都在现网跑通。
12.25日上午7:00,大家买了早点,吃完。让大家小憩一下。
12.25日上午7:00~8:00,寂静!暴风雨前兆!独自坐在会议室,面对乱麻一样的白板上各种讨论,最后再全面整理着思绪。敌人会从哪儿攻击?
12.25日上午,8:00~9:00,各单位陆续就岗,作战室开始工作。已登录用户5万,暂时未见系统异常。
12.25日上午,9:00~9:30, 流量激增一倍,用户登录10万,预期用户肯定会超过20万,作战室,启动预警。
三、狂风暴雨
12.25日上午,9:30~9:40,新增2.5万用户,主站系统开始感受到压力,页面响应开始有些变慢,仍在可接受范围。
12.25日上午,9:40~9:50,新增4万多用户,系统压力明显增加,网络负载很重,有部分系统开始告警。该关闭的服务,立即关闭。
12.25日上午,9:50~10:00,新增7万多用户。已越过警戒线!系统已产生大量告警,网站访问已出现较重卡顿。作战室内紧急讨论,先启动预案试试!
于是,试着开启了预案设备,然而,惊讶地发现,切换了不到几秒钟,预案设备全部宕机!又手工启动一次,结果一样!冲击力之强,完全超出了我们的想象!
12.25日上午,10:00~10:05,5分钟里又激增6万多用户,已超过30万用户堵在抢购门口了!现在预案设备出问题,原因来不及排查,只有3分钟就开始抢购了!我们在作战室内看着激增的流量,拥塞的网站,大量系统告警,空气都凝结了。只能孤注一掷,就用之前老方案去扛了!
12.25日上午,10:05~10:08, 在各种卡堵之下,还是又新增了6万用户,差不多40万登录用户堵在门口,还有一群未能完成登录的堵在各条路上,网络带宽达到极限。到点了,开闸!
四、一叶扁舟
如果用什么来形容当时的心情,立即闪在我脑海中的,就是《完美风暴》中船长Billy Tyne最后决定,掉转船头,直向风暴中心!最后船撞在如山的浪墙之上,失速沉没!
可怜的活动抢购系统,确如在茫茫大海之中,孤独面对狂暴风雨的一叶扁舟,随时会被巨浪吞没!
开闸之后,我们紧张地盯着订单,时间一秒一秒地过,每一秒都象是一记重锤敲击在心头,心中默算着,普通用户下完订单的时间。
10秒!首个订单出来了!
耶!大家都紧握拳头!活着!我们的小船还没沉没!虽然艰难,但顽强地活着!
网络带宽处于高位,很多子系统出现异常,不能响应请求,最不可理喻的,是大量异常与告警,但服务器CPU并没耗完。
拥挤!拥挤!还是拥挤!
但活动子系统,还坚强地活着,它的性能无法达到预期的能力,在前面很多环节的拥塞,会让很多人不能顺利地完成下单,尤其很多人会去重新刷页面,实际基本就更没机会。订单每秒都在增长,没有期望的快,但在稳中有升,在逐步提升下单速度中。
有些服务器始终可以正常工作,有些服务器就是不能正常工作,内部局域网有异常丢包!
五、风暴退去
10:16分,活动结束!
10:30分,活动结束十几分钟了,压力仍然巨大,又新增十几万用户!
12:00,用户达到60万人,中午时分,压力开始因饥饿而缓解,人总是要吃饭的。系统访问总算恢复正常。
下午,主要骨干休息,后备组收集各系统日志!将原关停服务逐步恢复!
第二章、快速反击
输得体无完肤,还能不能再战?敢不敢再战?
示弱!但不怯战!
拿着小学算术(见后),与各周边协商讨论方案,提出降低部分体验,如页面精美度需要牺牲,用户购物要分段完成等,最重要的,主站在活动期间隐身示弱!最终方案获得认可,全力以战!
六、输无可输
12.25日 19:00,作战室几个骨干一起坐下开会讨论。
气氛很压抑沉闷,大家已很疲惫,但结果很差,历来新品首发,总是VMALL超过其他平台,今天未达预期,系统被拥挤得不行,在心声上也被痛骂,大家都深感惭愧。
会议开始的几分钟,大家都在沉默,看着大家的神态,我也重新整理着头绪。
首先,我们必须接受这个事实,我们的方案没有经受住考验。
至于原因,我们还需要花相当的精力去追查,但显然也不是几天时间能查透彻的,各系统日志都是海量的,要分析出根本原因,核心环节,是要花费不少时间的,而下次面对的问题可能不同,而下次就是12.31日的二轮抢购,留给我们的时间只有5天!因此,我们先保留现场,保留各类错误日志,待进一步分析。
毫无疑问,我们现在最重要的是重拾心情与信心,要打一场快速反击战!
其次,我们退无可退,31日二轮抢购,压力不会降低,可能更高。正如前面的分析,系统拥塞,会被动地成为3C热度上升的助力器。再加上,二轮产量远远超过首轮,必须要趁热大量出货。系统如果再瘫,那就没有然后了。
基本问题点:
1. 预案失效。 NGX分发集群,完全未能扛住流量。 预案设备中,出现大量内网丢包,必须要查明。这让我们死得不明不白。
2. 不符合预期的动态请求量。首页、3C详情页都是静态化的,按理用户应主要访问的就是这两个静态页面。为什么会有大量动态访问?为什么不符合设想的模型?
3. 看不见的瓶颈。有些服务器坚强,有些服务器脆弱,很多服务器并没看到性能达到瓶颈,为什么。这和测试模式差异很大。
(这些问题,我们联合企业云一起,在二轮抢购(12.31日)活动之后,结合31日现场数据观测,参数调整,最后给出相应的分析。有两个底层的问题,一个是云平台组网方案中依赖iptables的安全策略,VMALL的分组、分域的网络安全策略较为复杂,iptables性能出现瓶颈,这在31日现场观测中被印证,通过临时调高参数规避;另外,VMALL的虚机数量庞大,虚拟机在物理机上分布有问题,面对这种同时达峰值的压力,多台虚机在同一物理机上,造成物理机瓶颈。)
应对31日的方案要点:
1. 紧急请求企业云支持,紧急增加设备;
2. 紧急请求企业云支持,将出口带宽扩大一倍,将主、备两路变为双主来紧急应对;
3. 紧急申请一批服务器,独立构建活动系统,并要求分散虚拟机(虽未分析出原因,但感觉虚机分布可能有问题);
4. 其他业务机房紧急申请一批服务器,作为节流阀之用,进行流量调控;
5. 暂停冒险使用NGX作法,仍采用多组LVS,应用层采用已成熟使用的Apache+Tomcat技术;
6. 主站系统过于复杂,软肋很多,在完成主站优化改造前,先示弱,抢购期主站隐身,全站只提供抢购服务,其他服务停止;
7. 抢购活动先做减法,将复杂逻辑去除,牺牲局部体验,保证全局体验,功能简化到极致;
8. 静态与动态隔离,静态部分用服务器数量去扛,为保障带宽,所有页面元素精简,控制页面大小;提示禁止刷屏,页面截获F5;采用本机时间,避免上行压力;
9. 页面各部分大小要求:全部图片大小不得超过50K;各JS+HTML等大小累计不得超过20K;上行请求不得超过2K;(可参见后面的小学算术)
10. 抢购活动,只干一件事,到时间点,用户一个点击即上报用户信息,服务端按时间排序。服务端分多组完全独立,各自平均配额,用完即止。
11. 抢购配额全部用完,就活动停止。活动停止后,进行后处理,将合法排队用户以提交时间为序生成订单。
12. 所有订单生成后,按区域放开主站,让用户完成订单地址填写并完成支付。
最大的风险,估计就在于主站开放,初步评估后处理需要半小时。