告别跨部门拉扯 | 为什么 APP 一搞活动就崩

周一早晨，运营小卉拿着上周末活动的复盘报告，一脸生无可恋地叹气

小卉火急火燎道地跑来找羽哥：“羽哥，我真的要崩溃了！好不容易策划个大促活动，结果周末晚上8点一到，咱们的APP又双叒叕卡崩了！用户骂声一片，说点个抽奖转圈转了三分钟。到底为什么啊？不就是平时那一套功能吗？”

羽哥停下敲代码的手，喝了口茶：“别急，小卉。这么说吧，你可以把咱们的服务器想象成一家“网红餐厅”。平时一天来几百个客人，咱们服务员（服务器）应付得游刃有余。 但你搞大促活动，这就相当于突然拉了几百辆大巴车的人，同一时间全挤进店里要点菜。服务员跑断了腿，后厨锅铲都抡冒烟了也做不过来。结果就是上菜巨慢，也就是用户体验到的“卡顿”。”

小卉：“啊？这什么意思？人多卡一下我能理解，那为什么后来直接“崩”了，想进都进不去了？”

蓝总正好端着咖啡走过来，眉头紧锁

蓝总：听你们在聊周末宕机的事儿。既然知道是有大促活动，那咱们为了这顿饭，临时多雇点“服务员”，多搬几张“桌子”不就行了吗？能用钱解决的问题，都不是问题，关键是临时加机器成本多少？能不能彻底解决？

安老师推了推眼镜，加入群聊：“蓝总，其实没这么简单。你可以这么理解，临时加服务器，这在技术上叫“扩容”。确实能解决一部分问题，但关键在于——瓶颈未必都在服务员身上。有时候是饭店的“门”太小（网络带宽不够），人全堵在门口进不来；有时候是“后厨”炒菜太慢（数据库读写压力太大）。服务员再多，厨师就那两个，菜一样出不来。更可怕的是，如果几千个人同时大喊大叫催单，系统一旦处理不过来就会集体罢工，这就是所谓的“雪崩效应”。”

小卉瞪大眼睛：“ 我明白了！那不就是说，光加服务员不够，还得拓宽大门，或者让厨师做快点？ 诶，安老师，那有没有那种……提前做好的快餐？大家一来就能端走，不用等厨师现炒！”

羽哥赞赏地点点头：“ 小卉悟性很高啊！这种提前做好的快餐，在技术里就叫“缓存（Cache）”。比如活动页面的商品图片、价格，我们提前放在缓存里，用户一来直接拿走，根本不需要去麻烦数据库那个“老厨师”。”

安老师：“对，除此之外，对于那些不是非吃不可的客人，咱们还可以发号排队，不让他们进大厅挤着，这才叫“限流”和“降级”。保证来吃招牌菜的大客户（核心交易链路）能吃好就行。”

蓝总眉头舒展：“ 这个比喻很直观。所以其实就是要做好几套组合拳：事前准备好“预制菜（缓存）”，期间做好“大堂限流”，必要时适当“加几个保底服务员（扩容）”。 行，既然技术路径清晰了。羽哥、安老师，咱们这周针对下个月的双十一大促做一次整体“压测”，评估一下要加多少资源。该扩容的扩容，涉及费用的地方出一个成本和风险预案，咱们请示公司尽快落实！”

小卉双手合十：“ 原来APP一搞活动就卡崩，里面学问这么大啊！下回活动我一定提前一个月跟技术部同步“预计就餐人数”！谢谢大家！散会！”