阿里一线工程师来告诉你：当你在双十一剁手时，他们在干嘛

From: http://www.mitbbs.com/article_t/JobHunting/32827377.html

发信人: wwzz (一辈子当码工), 信区: JobHunting
标  题: 阿里一线工程师来告诉你：当你在双十一剁手时，他们在干嘛 (转载)
发信站: BBS 未名空间站 (Wed Nov 12 12:53:36 2014, 美东)

【 以下文字转载自 Programming 讨论区 】
发信人: wwzz (一辈子当码工), 信区: Programming
标  题: 阿里一线工程师来告诉你：当你在双十一剁手时，他们在干嘛
发信站: BBS 未名空间站 (Wed Nov 12 12:53:06 2014, 美东)

阿里一线工程师来告诉你：当你在双十一剁手时，他们在干嘛
2014-11-12 储晓颖 观察者
作者：储晓颖（支付宝技术研发工程师）

本文系观察者网独家刊发，转载请洽微信号：guosijiaaa。

亲，当昨天晚上你为了抢单通宵奋战时，我，一名阿里巴巴的一线员工，也正和你同舟
共济沉浸在抢单的狂（bai）喜（jia）中，看见那个闪来闪去不断刷新的大盘了么？所
有人都像在证券所盯着股票大盘一样，看着红红绿绿的各种数字曲线跳动波动然后跟着
兴奋紧张。
而我，就是做这些大盘的。

这已经是我经历的第六个双十一了，对于阿里人来说，双十一就像高考，每年都要复读
，每年的题目还都比去年难很多……


对于阿里人来说，双十一就像高考，每年都要复读，每年的题目还都比去年难很多……

亲今天购物一定很担心抢到单系统卡壳付不了钱，这是想败家都不给机会的节奏啊。作
为一名苦逼的阿里程序猿，我和亲一样同呼吸共命运，亲担心的也正是我们担心的，这
也是为什么，每年都需要需要这么多员工通宵达旦灯火通明的一起来支撑双十一，而不
是随便安排几个运维同学值班就够了。

为了解释这个复杂的代码问题，先来举几个栗子吧。

第一个栗子：

如果你是个程序猿，你做了一个最简单的B2C网站，网站的主流功能必然是面向用户的
订单、购物车等“前台业务”；同时也必然会有一个“后台”，给你的小二（运营人员
）提供运营管理功能（新增营销活动、编辑店铺信息、修改商品信息、查询历史订单）
。然后有一天你们要办一个非常重要的促销活动，用户蜂拥而至，突然一个小二做了一
个非常复杂的历史订单查询（产生了一个嵌套好几层的SQL），而不幸的是你的系统又
没做读写分离（读写操作在同一个DB），DB负载本来就飙升好几倍了，这一下直接干倒
，多米诺效应拖垮了web前台，网页404——促销成了微博上茶余饭后的笑话。

点击查看大图。
多少人看着红红绿绿的各种数字曲线跳动波动然后跟着兴奋紧张

怎么避免这种事情？

第二个栗子：

程序猿应该都熟悉淘宝的tair缓存技术（双十一能成功，它居功至伟，大量的商品信息
都是缓存其中，细节不多介绍了）。

现在问题来了，如果量少，怎么玩都可以，但如果量大呢？

假如你有100台机器可用于部署tair。然后你参与大促的商品一共有100万件。按照最简
单的负载均衡思想，应该把100万件商品的信息，平摊到100台tair上，每台缓存1万件
商品详情（我们假设一台tair是缓存不了100万件全部商品的，那就必然要有所分工，
即使不是按商品的粒度，也可能会按其他更粗的粒度来分工）

现在你的运营过来告诉你，根据市场行情的调查和营销力度的把控，今年大促秒杀
iPhone6的PV可能会达到几百万、电饭锅的PV应该是500万，电吹风是200万……同时今
年又是iPhone6刚刚推出、正值风口浪尖的关键时刻。

如果是我，肯定拼了老命、赔了老本也要保住iPhone6的秒杀。至于电饭锅，让它自生
自灭吧！所以我可能会把90台tair都用于iPhone等5万个重点热门商品，10台用于剩下
的95万其他商品。（咳咳，以上所有数字纯属YY）

每年春运，大家都吐槽12306的排队，那么问题又来了——如果你的代码真的已经写得
很好了，机器真的不够用怎么办？

只能排队啊亲！

这个问题也让各个银行都感到头疼。银行啊！大型机啊！都搞不定啊！
所以如何优雅的“降级”，是阿里这几年技术成长的一个重点。想做优雅的排队？对不
起，首先你要异步化，否则就只能暴力的把用户拦在外面；想异步化？对不起，你是支
付宝，你是金融系统，在异步链路下依然要保证强一致性（总不能告诉用户购买成功、
钱却等了1分钟才扣）。

就算做到这些了，还要一个把并发编程思想发挥到极致的queue中间件，不仅能有条不
紊的削峰填谷、蓄洪限流，还要能随时接收参数调整，实时动态并发的改变阀门阈值（
什么概念？一点点的差错、1ms的差错，就会导致海量的订单没有按预期流动。）

即使这些都已经做的很努力了~还是要不停的改进！能不降级就不降啊、能不限流就别
限啊——看看每年的吐槽就知道了，技术上还是有很多不足的。

试想在第一个例子的情况下，大促销开场高峰期要关闭部分后台的复杂查询功能（甚至
是“前台”的次要业务），小二和客服的某些服务就会暂停，用户投诉就会上升，就要
启动事先准备好的缓和对策，等到压力稳定，要立刻恢复被降级的服务，小二和客服立
刻得到通知尽快去解决拖延已久的问题、安抚生气的用户。

银行顶不住了怎么办？收银台引导啊，让用户用扛得住的银行卡啊！充值送红包啊，让
用户多用支付宝余额啊！银行的量还降下不来怎么办？多送点红包啊！300不行送500啊
！运营找财务拨钱来发红包啊！决策小组亲自审批啊！营销规则要立刻发布更新啊！这
一切要在几分钟内完成啊！就酱紫……

想要把整个双十一玩转，需要PD、运营、中间件、业务系统、决策小组、客服等N多个
部门一起合作。因为在这么大的数据量面前，技术上纠结的程度已经具体到电饭锅了。

所以亲历双十一是什么感觉？

就是你看到作战室（超大会议室）里十几个大屏幕上翻滚的各种业务指标、系统数据，
各种红红绿绿的报表曲线提醒着每一秒钟的业务健康情况、决策执行情况、降级损害程
度……

然后决策小组的一帮最高指挥官通过这些数据做出各种决策，有些闲庭信步、有些壮士
断腕。

运维人员和系统owner以最高效的方式执行决策并跟踪反馈决策效果。

DBA、中间件的同学盯着自己的DB、系统在强大的压力下随时准备申请执行预案（还能
撑一点！加油啊儿子！我靠不行扛不住了、首架我要执行Plan B！……）

运营和客服的同学更不用说了，已经忙翻天了，她们可是要根据决策小组的决策不停变
换工作策略！

至于我？屏幕上的数字还在动，是准的，够用，我才能安心地过来写文（tu）章(cao)
啊！