高流量本身不是灾难，灾难是流量全怼到源站脸上。那些本该被边缘挡住的请求，因为缓存策略没配好、动静没分离、或者干脆没上CDN，一波波穿透到后端，把数据库和Web服务器一起打趴下。今天咱们就聊聊，流量高峰期到底怎么给源站卸担子。

最基础也是最有效的一招，是把静态资源从源站剥离出去。图片、CSS、JavaScript、视频这些内容，天生就该交给CDN处理。用户访问时直接从最近的边缘节点拿，根本不用问源站一句。但这里有个坑：如果CDN缓存命中率上不去，回源请求反而会增多，带宽成本飙升。有人实测过，命中率从百分之九十几掉到六十几，源站带宽消耗能翻一倍不止。所以配缓存规则的时候，得按资源类型分清楚——商品主图这种更新慢的，缓存设长一点；活动Banner这种频繁换的，设短一点或者配合主动刷新。

如果业务有大量文件更新，比如资讯站每天发几千张新图，单纯CDN可能扛不住持续回源。这时候可以在CDN和源站之间再插一层对象存储做“伪源”。文件第一次被请求时，CDN回源拉到对象存储里存着，后面再有请求直接从对象存储走，源站只被问一次。用存储成本换带宽成本，账算下来往往是划算的。配合生命周期规则把冷数据沉降到低频存储，还能进一步省钱。

动静分离是另一道防线。Nginx处理静态文件的效率比Tomcat这类应用服务器高得多，让Nginx在前面挡着，只把动态请求转发给后端。配置起来也不复杂，location里用正则匹配静态资源后缀，直接返回本地文件；匹配到动态路径，再用proxy_pass往后扔。有些云厂商还支持智能压缩，Gzip或Brotli把文本资源压掉百分之三五十，传输更快，带宽也省了。

动态内容的压力主要落在数据库上。缓存是必须上的，Redis或者Memcached把热点数据扛住，查询请求先问缓存，命中就直接返回，落库的请求能少一大截。但要注意几个坑：缓存穿透——查询一个压根不存在的数据，每次都穿透到数据库，布隆过滤器可以挡一下；缓存雪崩——大量key同时过期，请求瞬间全打到数据库，过期时间加随机偏移能缓解；缓存击穿——某个热key失效时并发请求涌入，互斥锁或提前预热可以应对。有些团队还会做缓存预热，大促前把热门商品数据提前加载到Redis里，避免瞬间回源。

再往上走，是架构层面的分流。Nginx或者HAProxy在前面做负载均衡，后面挂多个应用实例，流量按轮询或者最少连接数分发。水平扩展的好处是，压力大了直接加机器，不用跟单台服务器的上限死磕。如果业务是微服务架构，服务发现和自动扩缩容配合起来，能做到流量越大、节点越多，源站单点压力反而可控。

最后一道防线是限流和熔断。不管前面挡得多好，总可能有突发流量穿透到后端。Nginx的limit_req模块可以限制单个IP的请求频率，防刷接口、防爬虫都管用。如果流量实在太大，超过了后端处理能力，该熔断就熔断——返回一个友好的降级页面，比让用户直接看502强得多。有些云厂商还提供用量封顶功能，带宽超阈值自动停服，防止恶意攻击把账单刷爆。

监控是贯穿始终的事。缓存命中率、回源带宽、数据库QPS、接口响应时间，这些指标得实时盯着。哪天命中率突然掉下来，可能是缓存规则被改了，也可能是新的资源类型没覆盖到。发现问题及时调，别等用户投诉了才回头看。

说到底，高流量时期保护源站，靠的不是单点硬扛，而是分层卸载。静态资源让CDN挡着，热点数据让缓存扛着，动态请求让多台机器分着，超出预期的流量让限流拦着。每一层卸掉一部分压力，源站才能稳稳当当地把核心业务撑住。

下次再遇到流量高峰，别急着给源站加配置。先看看CDN命中率够不够高，缓存策略够不够细，动静分离做没做彻底。很多时候，该花的钱没花在该花的地方，该配的参数没配到位，才是源站被压垮的真正原因。