七、小学算术
带宽算法
活动前几分钟,集中登录用户,参考前文的用户变化,按2倍峰值系数计算,至少有1万CAPS。
临门最后一脚,假定100万并发用户规模,各机器本地时钟偏差平均按10秒分布,则有10万CAPS。
CDN带宽:1万CAPS* 50K *8bits= 4G
主站下行带宽:1万CAPS*20K*8bits=1.6G
主站上行带宽:10万CAPS * 2K * 8bits = 1.6G (假如用服务器时钟,没有本机时钟差异,是100万CAPS,16G带宽,我们机房带宽达不到)
这是小学生可以熟练计算的,当每秒请求数高到几万,甚至几十万时,小问题都是大问题。普通商城,一个页面超过1M大小很常见,在高并发下,带宽就不够用,不堵死得花很大代价,要知道中国的带宽资源是相当贵的。
后来我们租用某公有云服务,对用户抢购时行为上报的统计,根据我们估算,显然我们的主机房带宽是不行的,就用公有云服务,结果一次活动上报,某公有云就直接将我们的活动统计扔到蜜罐中了,流量太大,被当成攻击了。
我们一次活动QPS高达95万! 一秒近百万的请求,这不是小数目!要精细地考虑消息大小,1K都是大消息,这对普通网站来说根本就是不会考虑的事!但这就是小学算术!如果预计正常有10万CAPS,得预留3~4倍压力,必须要考虑非正常的大量请求!包括可能的恶意攻击请求!
在12.25之前,我们对小米的抢购模式是有怀疑的,总认为是宣传效果,但实际来看,几十万人集中在一点来抢购,是有可能制造出几分钟十万单奇迹的。后来,我们找小米的资料,发现大家在技术上都是经历同样过程,最后选择的方案也类似。和小米相比,在对用户理解上,体验设计上,我们还差很远。
八、太祖长拳
最后的技术方案,没有什么技术含量,使用的是最基本的技术。
天龙八部中,聚贤庄一战,乔峰以太祖长拳将一众少林高僧打败,那是乔峰武功已进入最高境界了。
我们自然不是武功层次高了,而是因为我们的武器库中就剩下最基本的基础技术,才能解决我们面临的峰值压力问题。
静态服务器只负责展示活动页面,就是纯静态HTML页面,通过JS控制页面逻辑,没有交互,在本地进行缓存;用了多组Apache集群承接压力,分布在北京、廊坊两个机房。
动态服务器只负责收集用户信息,进行排序与配额管理,然后生成临时文件;也是多个集群,各机器完全独立,配额平均分配。
另外,我们在其他机房部了几台Apache服务器,作为节流阀使用,流量分配则要根据压力情况调整。
在活动期间,先将主站隐身,用户无法访问到主站,避免主站去承载压力。
最后,就是根据临时文件,来生成用户的订单,因为没有收货地址信息,我们就先临时编个地址“请修改收货地址”,以提醒用户及时修改。(后来,发现很多用户不改地址就支付了,没法发货。这与我们的想像差异较大,也很让人困惑,于是我们就对这类订单,进行调整,不改地址,不让支付)。用户有了订单后,就可以变更收货地址,去完成支付。完成所有订单生成之后,将主站再开放出来。考虑的是主站也分省逐步放开,避免流量太大,对主站压力过大。
九、他山之石
小米是值得尊重的对手,其创造的互联网饥渴营销模式,不断被学习,仍未被超越。在拿到小米IT介绍抢购系统分享胶片之后,有种似曾相识的感觉,也给大家分享一下。
强调:以下内容全部摘自3月份获得的小米韩XX的胶片,读者要换个角色先,只有兰色字体是我们的点评。
看我们的流量模型,与下面小米的模型,那叫一个相似啊:)
1 然后,服务器抗不住,雷老板出来道歉,我们更抗不住。
2 我们的案例是独特的:市场的爆红,技术进化还没有跟上,没有时间给我们慢慢进化。
(似乎IT研发工程师,总会面临类似问题,我们的系统架构优化也还没搞完呢,突然就来荣耀3C活动了)
3 上百万人在门口啊,几百万预约,10万的QPS,4G的机房带宽,活动期间几千万次访问。
4 所有苦难的经历,以后都能笑着说出来。其实,这套抢购系统从构思到上线,只有不到一周时间,这都是被逼出来的!
(我们比当初小米的优势,在于12年首次活动时,我们就意识到要将抢购独立于主站;我们的问题在于后来没有什么流量压力,于是各种需求加了进来,对抢购流程添砖加瓦,增加了好多复杂功能,也就牺牲了抗压能力。)
5 为什么是我做?这么重要的系统,有7,8个人比我更适合做。都问过了,他们都没空。
(华为公司内比VMALL技术NB的多了去了,随便拉个团队,应该都可以解决问题。可是除了心声中有人,实际谁都没空也没职责来搞。唯一著了名的杨工也早就升级去搞运营了,剩下开发的活,还得让无名去做不是。)
6 当时抢购的现状
(在首次抢购时,我们就遇到锁的问题,对抢购单品的库存操作,大量并发是对单条记录的操作!这是与普通概念上的DB并发性能不是一个概念。)
7 在创业公司中,你解决不了问题,就会成为问题,被解决掉!市场提出了需求,他们是甲方。甲方虐我千百遍,我待甲方如初恋。
8 限制条件
(是的,我们也只有5天时间,做这样的独立的抢购,人多了也没用,我们也就是2~3个骨干投入)
9 服务器为什么撑不住?
直接走商城,真是无知无畏啊!
(谁要是事先知道流量压力,用户行为,都可以提出NB方案的,可惜事后诸葛总是多过事前诸葛,我们就只能事后才分析到问题,惭愧。有本社会学方面的书《错觉:为什么我们视而不见,转身就忘或自命不凡?》,该书非常值得一读)
10 继续优化商城?
(我们没有外援组,就算是内部解决,思路也得一样,约束条件在那儿。)
11 放弃优化商城,是最重大的设计决定:直接导致先抢资格,再去商城下单的基本结构。
(回头再看我们当晚的决策,得感谢小米,因为之前实际参与抢购的经验,给了我们参考,现在我们也得回到小米的路上,当然,我们也做了些优化,不用再去下单了。)
12 因为我是应急招来增援的,所以,能跳出原有系统思考。否则,钻了牛角尖的话,会走更多弯路。
(没人给我们应急,但我们哪敢钻牛角尖啊,活命是唯一任务。)
13 怎样撑住?
(12.25日痛苦的经历,让我们更加小心,商城主站就干脆活动期间隐身了。主站的优化,不是现在能短时搞定的,首先要让活动完成,然后才有机会。不能再冒险了,还是用太祖长拳吧。土没事,可靠最重要)
十、半场胜利
在经历了几天恶战,又是一个通宵之后,战斗就要打响了。
就在战斗打响之前,我们的节流阀方案遇到问题,备份机房的Apache服务器不稳定,出现异常,没有时间去解决了,当即决定弃用,所有流量流向主战场,压力山大。
抢购系统开发测试部署上线,就没有时间了,令人担心的是后处理工具,没有时间去验证、测试充分。
10:08,准时开战!
10秒,战斗结束! 超越历史的海量订单就瞬间完成了!
销售部督战同事都不敢相信,实际情况就是如此,所有的准备,辛苦,都在这一瞬结束!
抢购系统成功抵御了海量的冲击!
赶紧挂出售完页面!
赶紧处理订单!
事后有很多人骂是假的,包括心声上骂的也一样,几秒就结束了,抢不到,但这不是假的!实际就是秒级时间,活动结束!晚1秒,可能就没机会,真正的超级秒杀!
果然,令人担忧的事情出问题了。后处理订单,是个相当复杂的过程,数据库处理很慢,订单量又大,原先估计的半小时,根本就不够用。去重,合法性校验,创建订单,核减库存等,整个过程花了差不多40多分钟。
然后将主站放出去,因时间有延迟,大家都有压力,没有遵循之前确定的分省开放的策略,结果一放开,大量用户都冲去修改订单、支付,立即导致系统拥挤,数据库压力相当大,最后是熬到中午吃饭,压力减轻,系统才缓解了。
这种方案,无法精准控制库存,也无法准确估计支付率,结果放单量过大,卖超货了。这对前端生产制造环节就产生压力了,要兑现一周内发货,必须加班加点来加大产出。不过这算是幸福的痛苦吧。
总体来说,这是半场胜利,证明了方案是可行的,可以有效保证抢购过程,剩下的主站性能解决,就提上日程了,那不是个短期内立马能解决的,需要花费相当大的精力来解决下半场的问题。日后的经历,也确实证明,那是一段崎岖的坎坷之路。
带宽算法
活动前几分钟,集中登录用户,参考前文的用户变化,按2倍峰值系数计算,至少有1万CAPS。
临门最后一脚,假定100万并发用户规模,各机器本地时钟偏差平均按10秒分布,则有10万CAPS。
CDN带宽:1万CAPS* 50K *8bits= 4G
主站下行带宽:1万CAPS*20K*8bits=1.6G
主站上行带宽:10万CAPS * 2K * 8bits = 1.6G (假如用服务器时钟,没有本机时钟差异,是100万CAPS,16G带宽,我们机房带宽达不到)
这是小学生可以熟练计算的,当每秒请求数高到几万,甚至几十万时,小问题都是大问题。普通商城,一个页面超过1M大小很常见,在高并发下,带宽就不够用,不堵死得花很大代价,要知道中国的带宽资源是相当贵的。
后来我们租用某公有云服务,对用户抢购时行为上报的统计,根据我们估算,显然我们的主机房带宽是不行的,就用公有云服务,结果一次活动上报,某公有云就直接将我们的活动统计扔到蜜罐中了,流量太大,被当成攻击了。
我们一次活动QPS高达95万! 一秒近百万的请求,这不是小数目!要精细地考虑消息大小,1K都是大消息,这对普通网站来说根本就是不会考虑的事!但这就是小学算术!如果预计正常有10万CAPS,得预留3~4倍压力,必须要考虑非正常的大量请求!包括可能的恶意攻击请求!
在12.25之前,我们对小米的抢购模式是有怀疑的,总认为是宣传效果,但实际来看,几十万人集中在一点来抢购,是有可能制造出几分钟十万单奇迹的。后来,我们找小米的资料,发现大家在技术上都是经历同样过程,最后选择的方案也类似。和小米相比,在对用户理解上,体验设计上,我们还差很远。
八、太祖长拳
最后的技术方案,没有什么技术含量,使用的是最基本的技术。
天龙八部中,聚贤庄一战,乔峰以太祖长拳将一众少林高僧打败,那是乔峰武功已进入最高境界了。
我们自然不是武功层次高了,而是因为我们的武器库中就剩下最基本的基础技术,才能解决我们面临的峰值压力问题。
静态服务器只负责展示活动页面,就是纯静态HTML页面,通过JS控制页面逻辑,没有交互,在本地进行缓存;用了多组Apache集群承接压力,分布在北京、廊坊两个机房。
动态服务器只负责收集用户信息,进行排序与配额管理,然后生成临时文件;也是多个集群,各机器完全独立,配额平均分配。
另外,我们在其他机房部了几台Apache服务器,作为节流阀使用,流量分配则要根据压力情况调整。
在活动期间,先将主站隐身,用户无法访问到主站,避免主站去承载压力。
最后,就是根据临时文件,来生成用户的订单,因为没有收货地址信息,我们就先临时编个地址“请修改收货地址”,以提醒用户及时修改。(后来,发现很多用户不改地址就支付了,没法发货。这与我们的想像差异较大,也很让人困惑,于是我们就对这类订单,进行调整,不改地址,不让支付)。用户有了订单后,就可以变更收货地址,去完成支付。完成所有订单生成之后,将主站再开放出来。考虑的是主站也分省逐步放开,避免流量太大,对主站压力过大。
九、他山之石
小米是值得尊重的对手,其创造的互联网饥渴营销模式,不断被学习,仍未被超越。在拿到小米IT介绍抢购系统分享胶片之后,有种似曾相识的感觉,也给大家分享一下。
强调:以下内容全部摘自3月份获得的小米韩XX的胶片,读者要换个角色先,只有兰色字体是我们的点评。
看我们的流量模型,与下面小米的模型,那叫一个相似啊:)
1 然后,服务器抗不住,雷老板出来道歉,我们更抗不住。
2 我们的案例是独特的:市场的爆红,技术进化还没有跟上,没有时间给我们慢慢进化。
(似乎IT研发工程师,总会面临类似问题,我们的系统架构优化也还没搞完呢,突然就来荣耀3C活动了)
3 上百万人在门口啊,几百万预约,10万的QPS,4G的机房带宽,活动期间几千万次访问。
4 所有苦难的经历,以后都能笑着说出来。其实,这套抢购系统从构思到上线,只有不到一周时间,这都是被逼出来的!
(我们比当初小米的优势,在于12年首次活动时,我们就意识到要将抢购独立于主站;我们的问题在于后来没有什么流量压力,于是各种需求加了进来,对抢购流程添砖加瓦,增加了好多复杂功能,也就牺牲了抗压能力。)
5 为什么是我做?这么重要的系统,有7,8个人比我更适合做。都问过了,他们都没空。
(华为公司内比VMALL技术NB的多了去了,随便拉个团队,应该都可以解决问题。可是除了心声中有人,实际谁都没空也没职责来搞。唯一著了名的杨工也早就升级去搞运营了,剩下开发的活,还得让无名去做不是。)
6 当时抢购的现状
(在首次抢购时,我们就遇到锁的问题,对抢购单品的库存操作,大量并发是对单条记录的操作!这是与普通概念上的DB并发性能不是一个概念。)
7 在创业公司中,你解决不了问题,就会成为问题,被解决掉!市场提出了需求,他们是甲方。甲方虐我千百遍,我待甲方如初恋。
8 限制条件
(是的,我们也只有5天时间,做这样的独立的抢购,人多了也没用,我们也就是2~3个骨干投入)
9 服务器为什么撑不住?
直接走商城,真是无知无畏啊!
(谁要是事先知道流量压力,用户行为,都可以提出NB方案的,可惜事后诸葛总是多过事前诸葛,我们就只能事后才分析到问题,惭愧。有本社会学方面的书《错觉:为什么我们视而不见,转身就忘或自命不凡?》,该书非常值得一读)
10 继续优化商城?
(我们没有外援组,就算是内部解决,思路也得一样,约束条件在那儿。)
11 放弃优化商城,是最重大的设计决定:直接导致先抢资格,再去商城下单的基本结构。
(回头再看我们当晚的决策,得感谢小米,因为之前实际参与抢购的经验,给了我们参考,现在我们也得回到小米的路上,当然,我们也做了些优化,不用再去下单了。)
12 因为我是应急招来增援的,所以,能跳出原有系统思考。否则,钻了牛角尖的话,会走更多弯路。
(没人给我们应急,但我们哪敢钻牛角尖啊,活命是唯一任务。)
13 怎样撑住?
(12.25日痛苦的经历,让我们更加小心,商城主站就干脆活动期间隐身了。主站的优化,不是现在能短时搞定的,首先要让活动完成,然后才有机会。不能再冒险了,还是用太祖长拳吧。土没事,可靠最重要)
十、半场胜利
在经历了几天恶战,又是一个通宵之后,战斗就要打响了。
就在战斗打响之前,我们的节流阀方案遇到问题,备份机房的Apache服务器不稳定,出现异常,没有时间去解决了,当即决定弃用,所有流量流向主战场,压力山大。
抢购系统开发测试部署上线,就没有时间了,令人担心的是后处理工具,没有时间去验证、测试充分。
10:08,准时开战!
10秒,战斗结束! 超越历史的海量订单就瞬间完成了!
销售部督战同事都不敢相信,实际情况就是如此,所有的准备,辛苦,都在这一瞬结束!
抢购系统成功抵御了海量的冲击!
赶紧挂出售完页面!
赶紧处理订单!
事后有很多人骂是假的,包括心声上骂的也一样,几秒就结束了,抢不到,但这不是假的!实际就是秒级时间,活动结束!晚1秒,可能就没机会,真正的超级秒杀!
果然,令人担忧的事情出问题了。后处理订单,是个相当复杂的过程,数据库处理很慢,订单量又大,原先估计的半小时,根本就不够用。去重,合法性校验,创建订单,核减库存等,整个过程花了差不多40多分钟。
然后将主站放出去,因时间有延迟,大家都有压力,没有遵循之前确定的分省开放的策略,结果一放开,大量用户都冲去修改订单、支付,立即导致系统拥挤,数据库压力相当大,最后是熬到中午吃饭,压力减轻,系统才缓解了。
这种方案,无法精准控制库存,也无法准确估计支付率,结果放单量过大,卖超货了。这对前端生产制造环节就产生压力了,要兑现一周内发货,必须加班加点来加大产出。不过这算是幸福的痛苦吧。
总体来说,这是半场胜利,证明了方案是可行的,可以有效保证抢购过程,剩下的主站性能解决,就提上日程了,那不是个短期内立马能解决的,需要花费相当大的精力来解决下半场的问题。日后的经历,也确实证明,那是一段崎岖的坎坷之路。