抢周杰伦演唱会票崩的那次，我才搞懂什么是负载均衡

去年抢周杰伦南京场演唱会票，我提前十分钟蹲在电脑前，连WiFi都特意切了离路由器最近的那个，验证码输到第三遍的时候，手指都按在提交键上了。

点下去。

直接跳502。

我当时对着键盘骂了十分钟，连楼下卖烤肠的阿姨都抬头看我。后来做运维的朋友甩了个截图过来，笑我这就是没把负载均衡做明白的典型下场。

排队买奶茶的队伍，其实就是最早的负载均衡

说实话，我之前一直觉得这是个只有技术人员才懂的黑话，直到朋友拉我在学校门口看了十分钟蜜雪冰城的排队场景，我瞬间就懂了。

最早那家店只有一个点单窗口，放学的时候几百个学生挤在窗口前面，店员手都抖，出一杯奶茶要等十五分钟，不少人挤了两分钟直接转身走了。老板心疼生意，后来一口气在门口摆了三个一模一样的点单台，每个台后面都站了个能接所有订单的店员，还专门安排了个兼职在门口引导——哪个点单台前面人少，就把新来的顾客往哪个台引。

你看，这跟互联网公司做的负载均衡有啥区别？没有区别。单窗口就是单台服务器，最多同时接几十个人的请求，挤多了直接死机。三个点单台就是三台性能一模一样的服务器，门口引导的兼职就是那个调度流量的负载均衡系统，核心目标只有一个：别把人都挤在一个地方，让每个窗口的人都能最快点到单。

我上次还遇到过特别傻的老板，明明开了两个点单窗口，但是只在第一个窗口前面拉了排队的警戒线，所有人都老老实实挤在第一个窗口，第二个窗口空了半小时都没人去。这就跟很多公司做负载均衡配错规则一样，白白浪费了硬件资源，最后还怪顾客太多。

你以为的”服务器崩了”，很多时候是调度的人摸鱼

说回上次抢演唱会票的事。朋友说他们当时接的那个售票系统，后台其实配了整整16台服务器，每台都能扛住近万人同时提交订单。结果当天负责调度的工程师临时改了规则，把所有进来的请求都优先发给第一台服务器。

第一台刚扛了三分钟就直接宕机了。

后面15台服务器还在机房里闲得转风扇，连个请求都没收到。你说气不气？我当时还以为是十几万人同时抢票把所有服务器都干废了，合着是调度的人脑子抽了？

很多人对负载均衡的误区就在这——觉得只要多买几台服务器，就不会崩了。哪有这么简单？负载均衡的核心从来不是堆多少硬件，而是把请求”不挤兑”地分到合适的节点上。就像你开了十家奶茶分店，但是所有顾客都只知道总店的地址，分店装修得再好，也帮不上总店的忙。

朋友说他们后来给那个售票系统补了规则，新的抢票系统会实时看每台服务器的负载，哪个节点现在最闲、离用户最近，就把请求往哪个节点发，哪怕再遇到十几万人同时抢票，也不会出现单台服务器被挤爆的情况。

你刷短视频不卡，全靠它在后台偷偷干活

不过话说回来，现在我们日常用的互联网产品，能做到从来不让你感受到”崩了”的状态，全是负载均衡在背后默默干活。

比如你刷短视频的时候，哪怕是遇到明星官宣、球赛绝杀那种全网同时刷一个视频的爆点时刻，你点进去还是能秒加载，从来不会让你对着转圈圈的图标等半天。这不是因为你家的千兆宽带有多神，是后台的负载均衡系统一直在实时调整流量。

好的负载均衡甚至会提前预判流量，比如知道周末晚上八点是刷短视频的高峰，就提前把闲的服务器开起来等着，而不是等崩了再临时抱佛脚。我上个月去西湖边玩，站在断桥上刷本地博主的杭州美食视频，加载速度比我家南京的千兆宽带还快。后来问了做短视频运维的朋友才知道，负载均衡直接把我周围三公里内的用户，都导到了离我最近的杭州本地机房节点，数据根本不用跨城传输，当然快。

我之前自己捣鼓过一个小博客，刚开始就我一个人写点日常，挂在一台最便宜的云服务器上，从来没出过问题。直到有次我写的南京美食攻略被个本地大V转了，一天涌进来几千个访客，直接把博客干得打不开了。我当时熬到三点钟，不停手动重启服务器，越重启越崩。后来还是朋友远程帮我加了个简单的负载均衡，把请求分到两台闲置的云服务器上，五分钟就恢复了正常。

我当时对着屏幕拍大腿。

早知道这么简单，我前一天就不会硬扛着不睡觉重启服务器了。

现在再遇到网站转圈的时候，我都不会急着骂网速差了，多半是那个负责调度的人，要么在摸鱼，要么规则配错了。对吧？