双十一零点刚过三秒，网站我点进某个限时折扣页面，太多转圈的人挤小菊花转了整整四十秒，然后弹出一行灰字：“系统繁忙，不上请稍后重试。去办” 稍后？网站等我一分钟后重新点进去，商品已经显示“已抢光”。太多这不是人挤我第一次被网站挤出门外了。服务器扛不住流量洪峰，不上说白了就是去办一瞬间涌进来的人太多，超出了它设计的网站处理能力。技术上有两条路：要么让网站变强，太多要么让人别挤在一起。人挤

让网站变强，不上最直接的去办办法是加服务器。可加服务器要花钱，平时流量低的时候纯属浪费。于是就有了弹性扩容——流量涨了自动开新机器，流量降了自动关掉。阿里云、腾讯云都提供这种服务，原理不复杂，但真正实施起来有坑。我见过一个电商团队，扩容脚本写得没问题，但数据库的连接池没跟着扩大，结果前端扛住了，数据库先崩了。那感觉就像你拓宽了高速公路入口，可收费站只开了一个窗口，车照样堵死在收费口。

另一种思路是让人别挤在一起。很多网站用排队系统，像银行取号一样。12306当年春运抢票，高峰期就靠排队策略，你提交请求后先进入队列，系统告诉你“前方等待人数：12580”，然后按顺序放行。这法子能保住服务器不挂，但用户体验极差——谁愿意盯着屏幕等半个小时？更聪明的做法是限流，比如只允许前一万个请求进入，后面的直接返回“活动已结束”。这招狠，但有效，至少不会让所有人都在那干耗着。

还有个操作性很强的技巧，叫静态化。把商品详情页、活动页面这些不怎么变的内容，提前生成成HTML文件，放在CDN上。用户请求根本到不了你的应用服务器，直接从离他最近的节点返回数据。我帮朋友的小商城做过一次改造，原来一秒钟最多处理两百个请求，把首页和详情页静态化之后，直接飙到每秒五千。费用几乎没增加，效果立竿见影。当然，库存查询、下单这种动态操作没法静态化，那就要靠缓存了——把库存数据放在Redis里，读的时候不走数据库，能扛住比平时大几十倍的流量。

但这些都属于技术层面的修补。真正治本的办法，是提前做好容量评估。我见过太多团队，平时不测压，上线前也不做压测，等到活动当天才发现扛不住。压测不是可有可无的流程，它就像消防演习，平时演练过，真着火的时候才知道往哪跑。用压测工具模拟十倍于平时的流量，提前把系统打崩一次，看看瓶颈在哪里，然后针对性地优化。这活儿不轻松，但比活动当天手忙脚乱强一百倍。

说到底，网站被挤爆不是技术问题，是态度问题。你愿不愿意为那可能只有十分钟的流量高峰，提前做足准备？有些公司觉得概率小，赌一把，结果真碰上了，损失的不只是当天的销售额，还有用户对你的信任。我经常跟朋友说，技术手段就那么几种，拼的是你肯不肯认真对待每一次可能到来的高峰。别等网站真挤不进去了，才想起该做点什么。