2026-11-14 07:53:08 k73游戏之家 作者：testai
站点流量一涨，最常见的场面是 CDN 面板上显示命中率九成多，源站带宽却还是被打满，访问慢得像没接 CDN 一样。很多人第一反应是加带宽，钱花了问题还在，因为真正吃源站的不是正常访问，而是那些绕过缓存或者必须回源的请求。这篇把回源的来路、缓存规则的坑和源站该怎么算容量讲清楚，都是在实际运维里踩出来的经验。
CDN 的逻辑很简单：用户请求先到边缘节点，节点上有这份文件就直接给，没有就去源站取一份存下来。命中率看着高，不代表回源压力小，因为回源的往往是体积最大的那一批文件，比如视频、安装包、大图，一个没缓存的请求就能带走几十兆带宽，几百个这样的请求叠在一起，端口瞬间就满了。
另一类常被忽略的流量是动态请求。接口、登录、下单这些必须实时到源站的请求完全不经过缓存，流量上涨的时候它们跟着涨，并且对延迟极度敏感。如果源站带宽被静态回源吃满，动态请求的响应时间会先崩，排在后面的请求连超时通知都来不及返回，表现出来的就是「页面能打开但点按钮没反应」，用户会以为是浏览器卡了，反复刷新，把回源压力又推高一轮。
再就是缓存过期的时间点。所有节点在同一时刻失效同一批资源，会在几秒内把回源请求堆到源站，形成周期性尖峰。原本支撑得住的机器，在这种瞬间并发下也会排队到超时，日志里一片上游超时，看起来像源站挂了，实际是缓存集中失效把事情放大了。
另有一种情况是多个域名共用一个缓存池。不同业务的内容混在同一个节点上，容量被互相挤压，热门资源刚被写入就被挤出去，命中率忽高忽低。给不同业务分域名、分缓存策略，情况会稳定很多，排查的时候也更容易看出是哪一摊在吃缓存。
参数带在 URL 上是最常见的原因。同一张图带上不同的随机参数或者时间戳，缓存节点看到的就是不同的资源，每次都要回源。很多统计脚本、分享组件会自动加参数，排查的时候把访问日志按 URL 去参数再统计一遍，命中率通常会明显改善。
缓存头没配对也会让节点不敢存。源站返回不带缓存标记，或者标记成不缓存，节点只能老老实实回源。静态资源该给的缓存时长要明确写出来，图片、字体、样式表这类内容可以给得很长，接口这类不要给。
Cookie 和鉴权会让缓存直接失效。带着用户身份的请求，节点无法判断内容是否千人千面，只能全部回源。把静态资源和动态接口分到不同域名下，静态域名不带 Cookie，这一项就能救回不少命中率。
文件太大也会被跳过。多数 CDN 对单个文件有缓存上限，超过就直接透传，不落地。视频切片、大安装包这类内容要按节点规则切分，或者单独走对象存储加 CDN 的组合，别指望一个大文件被边缘节点完整缓存；节点覆盖不足同样会拉低命中。用户集中在某个区域，而那个区域的节点容量小或者节点少，请求会被调度到远端节点，回源路径变长、缓存碎片化。看一下访问来源的地域分布，和节点分布对不对得上，这一步经常能发现明显错配。
配置更新后的预热没做。缓存规则一调整、源站一换版本，边缘节点的旧缓存全部失效，接下来一段时间全是回源。正确的做法是变更前先降频、变更后主动预热热点资源，把回源压力摊开到几分钟里，而不是一口气全砸下去。原文里提到的那台大容量存储机型，配合对象存储做冷热分层，能把这部分压力接住不少。
估算的顺序是先把回源流量单独拎出来。总流量乘上回源比例，才是源站真正要承载的部分，回源比例取决于命中率和文件大小分布，不能拍脑袋。把一周的回源流量按小时画出来，峰值出现在哪几个时段一目了然，也能看出是不是跟业务发布节奏对得上，这一步做完再谈配容量才有依据。
接着看并发连接数，不能只盯着带宽，这两项经常不同步。回源请求的特点是连接数多、单个连接不连续，机器扛不扛得住更多取决于连接处理和磁盘随机读，而不是端口标称有多大。源站机器在选择上应该把内存和磁盘的随机读写放在前面，核数排在这两项之后，云途这两档里 800 元档那台的机械盘适合放大文件，350 元档那台的固态更适合做动态请求和小文件回源。
留余量要按峰值而不是均值，这条几乎是最容易被省掉的一步，也是后面所有估算的前提。回源流量在促销、发布、被抓取的时段会出现数倍于均值的尖峰，按均值配容量等于每个月都要救一次火，算得越细越省钱，也越不容易在关键时刻掉链子。经验值是按 95 分位的峰值再上浮三成来定带宽和连接上限，这个余量能吃掉大部分突发，剩下的靠限速和排队兜住，机动的一套扩容预案留在手上更踏实，临时加钱办事总比事后赔体验划算，这笔预算早留早安心，别等到报警了才想起来算。
规则要按资源类型分，不要按目录一刀切。图片、视频、字体这类不变的内容给长缓存，并且允许节点忽略参数；样式脚本这类带版本号的按文件名区分，版本一变自然就换了地址；接口一律不缓存。分完之后再看一遍命中率，通常会比统一规则高出十几个点，这个提升几乎是免费的，不需要多花一分钱。
忽略参数要谨慎。忽略掉全部参数会让某些真正依赖参数的资源互相覆盖，返回错误的版本。做法是先统计哪些参数是无意义的，只忽略那部分，把规则写成白名单而不是黑名单，出错概率小得多。
404 也要有缓存策略。被扫描器乱扫的地址会持续回源，源站每次都认真处理一遍再返回 404，白白消耗资源。给 404 设一个短缓存，能把这类无效回源挡在边缘，日志也干净很多，缓存键的设计也要跟着一起细化。按域名、路径、少量必要参数组成缓存键，既保证不同内容不串，也不至于因为一个无关参数把缓存打散。缓存键设计得差，命中率怎么调都上不去，这是很多站点长期命中率偏低的根子。
预热要有清单。把首页、栏目页、热门详情页、高频接口的静态部分列成清单，变更完成后按清单批量请求一遍，让节点提前把内容拉下来。预热请求要控制速率，别把预热变成第二次回源风暴。
失效要能精确。改一篇文章只该失效那一篇对应的缓存，而不是全站刷新。支持按 URL 或标签失效的 CDN 要优先用，做不到的就在更新时用版本号前缀，让旧缓存自然淘汰，避免一次全站清空。
监控要盯回源比例和回源错误率两个数。回源比例上升说明缓存效率在退化，回源错误率上升说明源站开始扛不住。这两个指标比命中率更能反映真实情况，也更容易定位到是哪类资源出的问题。
边缘节点回源失败时，默认行为通常是直接给用户报错。可以把失败策略改成回退到一份静态的快照页面，或者用较短时间内的旧缓存顶着，让用户至少能看到内容。这一步不解决根本问题，但能避免一次源站抖动变成全站不可用。
源站要限速。给回源单独设一个带宽上限，让 CDN 的回源请求不超过这个额度，剩下的留给动态请求和后台任务。限速会让部分回源变慢，但保住了核心业务，这个取舍在流量高峰期非常值得。
多源站要真的分流。配置多个源站时，注意权重和健康检查，别把全部回源压到一台上。健康检查的间隔和失败阈值要调得合理，太敏感会在源站稍有抖动时把它踢掉，剩下那台瞬间被打满。
降级方案要提前写。命中率掉到阈值以下、回源错误率持续高于阈值，应该自动切到精简模式：关掉非核心的图片和脚本、暂停预加载、把部分动态接口改成静态兜底。这套开关平时就要演练，真出事的时候才敢按。
日志要能串起来查。边缘侧的请求日志、回源日志、源站的应用日志要能通过一个请求标识对上，不然出问题只能三方各看各的，互相推。加一个请求头传递标识，成本很低，排查效率提升明显。
压测要模拟真实场景。只用固定 URL 压测，缓存全命中，测出来很好看但没意义。压测要包含大量未命中请求、带 Cookie 的请求、大文件请求，把回源路径也压一遍，才知道真实的容量边界在哪里。
容量规划要跟着业务走。新品发布、活动上线之前，先估算新增流量和对应的回源量，提前扩容或者临时提高缓存时长。事后补救的成本远高于事前算一遍，尤其是那种「上线十分钟后开始变慢」的场景；另一个常被忽略的细节是 TLS 握手。回源如果走加密连接，握手开销会随连接数上升，源站的 CPU 会先于带宽见顶。开启连接复用、减少握手次数，能把这块开销压下去不少，对大流量站点是实打实的收益。
先判断瓶颈在哪。带宽打满、磁盘读写饱和、CPU 被握手吃满，三种情况的解法完全不同。抓一轮峰值时的监控数据，看哪个指标先到顶，就知道钱该花在哪，别一上来就换更贵的机器。
如果瓶颈是磁盘随机读，换固态或者加内存做缓存比加核数有效。小文件回源是典型的随机读场景，机械盘在这种负载下性能衰减很快，换成固态之后同样的机器能多扛几倍请求，这是性价比最高的一次升级，改完再看回源耗时和排队长度，通常能掉一半以上。
如果瓶颈是带宽，加节点或者换更大端口的机器更直接。跨境线路上的实际吞吐往往受制于国际出口，标称带宽跑不满是常态，选机型的时候要按实际可用的比例打折算，别按标称值规划容量，两三百兆的实际吞吐就该当作上限看待。
如果瓶颈是边缘命中率，那问题不在源站。把缓存规则和缓存键重新梳理一遍，比换机器省钱得多。命中率从八成提到九成五，回源量直接降一大截，等于凭空多出几倍的源站容量，这笔账算下来比换机器划算得多。
真的需要扩容时，优先做横向扩展而不是纵向升级。两台中档机器分摊回源，比一台顶配机器更抗故障，也更容易做灰度。跨渠道对比一下，SixTyNet 的洛杉矶机型适合做海外回源的第二个点，多个源站分布在不同区域，回源路径短、单点故障的影响面也小，比把预算全压在一条线上稳当。
