今晚8点，双11尾款与现货同步开卖。几分钟内，大量用户发现淘宝“崩了”：下单键点了没反应，结算页迟迟出不来，手里的优惠眼看要飞。“淘宝崩了”的话题再次冲上热搜，话题流里夹杂着“我下单的时候正常”的自嘲。截至发稿，淘宝未回应今晚的故障原因。但把最近一个多月的几次“崩”放在一起看，“买东西的人太多了吗”这个追问就有了不一样的答案：高并发宕机几乎从不是全站流量洪峰压垮了机房，而是太多人同一时刻，挤过了架构里最窄的那道门。知乎微博微博
用户骂“服务器宕机”时，平台承受的其实是页面打开、接口请求、订单创建三种压力：前两种可以靠缓存和带宽摊薄，最后一种必须让系统真刀真枪地记账，完全不是一回事。平台的对策是把三件事拆开：商品图、活动页在开售前就被推到CDN边缘，刷页面基本不回源；网关层再做第一轮拦截，未登录的挡掉、疯狂刷新的限流、脚本尽量在这一层处理掉。真正走到下单环节的请求已经少了一大截，而这正是这套体系常年打磨的量级——2019年双十一，天猫订单创建峰值达到每秒54.4万笔，2020年为58.3万笔。所以真正的悖论在于：平台最不怕“多”，最怕“同时”——同一秒挤进同一个瓶颈的集中。知乎知乎
一个多月的三次“崩”，触发点各不相同
9月3日上午，淘宝App突发大面积服务器故障：订单页面一片空白，商品无法浏览，支付卡在半路。淘宝客服当天午间致歉并称页面已恢复，给出的解释只有一句“系统出现一点问题”。那是一个既无大促也无节假日的工作日上午，流量平平，指向的更可能是后端变更或底层组件，而不是人太多。每逢这种热搜爆掉，从业者都心知肚明后台在发生什么：“底下又有多少人在默默翻看最近的上线内容”。知乎知乎知乎
10月16日晚8点则是另一种剧本：iPhoneDuo开售瞬间，苹果官网和各大电商平台同时被挤爆，淘宝页面也崩了一阵。今晚又叠上了第三种情况：付过定金、等着放价的订单，与“20:00尾款+现货同步开抢”的抢购人群，在同一分钟汇入同一条支付链路。微博微博
时间轴再拉长，2023年11月12日的“淘宝崩了”“闲鱼崩了”“阿里云盘崩了”集体上热搜，源头是阿里云出故障。一个购物App宕机可能只是应用问题，生态级的底层组件宕机则让全家一起“陪葬”——9月3日那次，用户就反映“支付宝、闲鱼也一起受牵连”。界面新闻知乎
为什么架构防不住：三个真正的原因
第一，热点没法“摊平”。 负载均衡可以把一百万次浏览分给一千台机器，库存扣减却不行——一件商品只剩最后一批时，所有抢购请求本质上要在同一个计数上排队。秒杀体系的设计哲学从来不是“扛住所有人”，而是“先把绝大多数人挡回去，只留下接近库存数量的请求”。可一旦入口过滤失准，排队就发生在链路最窄处，表现就是“页面能刷开、下单死活没反应”——与今晚用户描述的症状一致。知乎
第二，防御机制会制造二次洪峰。 被限流或超时的用户不会干等，刷新、退后台重进、切换网络，一次请求变成十次。支付链路更微妙：状态同步稍有延迟，用户看到的就是“扣了钱却还待付款”。iPhoneDuo开售当晚的苹果官网就踩中了这个经典坑，“订单已成功扣款，但页面仍提示支付”。幂等性失效时，重试越真诚，系统越堵。微博
第三，变更与流量总是同时出现。 大促前夕，海量新代码、新配置、新优惠规则集中上线，而它们迎接的第一波真实流量，恰好是全年最陡的那条曲线。今年双11的规则变化不小：“全面取消了跨店满减，改成了官方立减和单件直降”。9月3日那次非大促宕机，已经提前演示过这个规律的镜像：“非大促期间宕机，暴露了峰值压力之外的技术隐患”。知乎微博
今晚崩了，用户能做什么
第一，别重复付款。页面报错时先查支付宝账单和订单状态，平台此前故障时就明确“官方提醒用户‘不要重复支付’”——异常状态下最怕钱和单对不上，反复提交只会加剧拥堵。第二，优惠过期不必慌：大面积故障期间的交易与优惠以系统留痕为准，客服此刻大概率“还找不着”，扣款有异议留好账单凭证，稍后申诉核对即可。知乎微博
“淘宝崩了”大概率还会在未来的某个整点准时出现。但对普通用户来说，值得记住的技术事实其实很朴素：现代架构从来不怕人多，怕的是所有人同一秒、挤同一道门。
