电商2

七、小学算术
带宽算法
活动前几分钟，集中登录用户，参考前文的用户变化，按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多分钟。
然后将主站放出去，因时间有延迟，大家都有压力，没有遵循之前确定的分省开放的策略，结果一放开，大量用户都冲去修改订单、支付，立即导致系统拥挤，数据库压力相当大，最后是熬到中午吃饭，压力减轻，系统才缓解了。
这种方案，无法精准控制库存，也无法准确估计支付率，结果放单量过大，卖超货了。这对前端生产制造环节就产生压力了，要兑现一周内发货，必须加班加点来加大产出。不过这算是幸福的痛苦吧。
总体来说，这是半场胜利，证明了方案是可行的，可以有效保证抢购过程，剩下的主站性能解决，就提上日程了，那不是个短期内立马能解决的，需要花费相当大的精力来解决下半场的问题。日后的经历，也确实证明，那是一段崎岖的坎坷之路。