为什么你的源站带宽账单一直降不下来？——CDN L2
故障定位思路
关于CDN L2，最值得先弄清楚的是配置边界和排错顺序。当你使用CDN加速网站时，大部分请求应由边缘节点直接响应，只有节点未命中缓存（即缓存缺失）时才会回源拉取数据。理论上，缓存命中率越高，源站带宽消耗就越低。然而实际运营中，很多网站的缓存命中率只能维持在60%-80%，剩余20%-40%的请求仍然要穿透到源站。如果回源数据量较大（例如高清图片、视频流或API响应），源站带宽成本会迅速攀升。
传统CDN采用单层缓存架构：每个边缘节点独立缓存内容，节点之间互不通气。当用户访问分散在不同节点时，同一个文件可能被重复回源多次。尤其在热数据集中度不高、访问地域分布广泛的情况下，这种架构的带宽浪费非常明显。要解决这个问题，不能简单增加单个节点的缓存空间——因为缓存空间总有限，而且热点会随时漂移。于是，二级子缓存（L2 Cache） 成为业内普遍采用的优化方案。
什么是二级子缓存（L2 Cache）？
二级子缓存本质上是一个位于边缘节点与源站之间的中间缓存层。你可以把它想象成一个“区域缓存枢纽”：多个边缘节点共享一个L2缓存实例（或集群），当某个边缘节点无法命中自己的本地缓存（L1）时，它先向L2层请求数据，若L2层命中，则直接从L2返回给用户，同时边缘节点自己也会缓存一份副本（L1），下次相同请求就能在本地响应。只有当L2层也缺失时，请求才会真正到达源站。
这种架构将单层回源变成了两级回源。L2层实际上起到了“缓存汇聚”的作用：多个边缘节点上的重复请求在L2层被聚合，大幅减少了回源次数。同样一个热门文件，原本可能被100个边缘节点各自回源100次，现在只需要在L2层回源1次，其余99次都在L2或L1直接命中。
L1与L2的典型差异
- L1（边缘缓存）：容量小（通常几十GB到几百GB），距离用户近，延迟低，主要缓存最热的内容，淘汰策略激进（LRU或LFU）。
- L2（二级缓存）：容量大（可达TB级），位置通常部署在核心机房或区域中心节点，延迟略高于边缘但远小于源站，缓存时间更长，淘汰策略更保守，用于吸收低频但仍有价值的请求。
简单理解：L1负责“快”，L2负责“全”。两者配合，既保证低延迟，又降低源站压力。
CDN L2：二级子缓存如何降低源站带宽成本？
成本降低的核心逻辑在于 提高了整体缓存命中率，减少回源数据量。具体体现在以下几点：
1. 消除“跨节点重复回源”问题
在单层缓存中，假设某个热门视频文件1GB，被分布在全国10个城市的用户访问。如果10个城市的边缘节点都没有缓存该文件，那么每个节点都需要从源站拉取1GB，总共回源流量10GB。而有了L2缓存，第一个节点回源后L2缓存了该文件，其余9个节点依次从L2获取（每获取一次也会在L1保存一份副本），回源流量仅1GB。这个案例中，带宽成本降低了90%。
2. 提升预热和刷新效率
当网站发布新内容或更新文件时，通常需要手动预热或刷新缓存。在单层架构中，你需要在所有边缘节点逐一执行操作，操作次数等于节点数量。而在L2架构中，你只需要预热/刷新到L2层，之后当用户第一次请求时，边缘节点自动从L2拉取新版本。这样既减少了管理复杂度，也避免了一次性回源风暴。
3. 容忍更长的缓存时间，降低源站动态查询压力
对于动态或半动态内容（如带有少量个性化的页面），边缘节点可能因为频繁的缓存失效而反复回源。但L2层可以配置更长的缓存保留时间（例如1小时），即使L1因为空间不足而淘汰了某个文件，L2依然保留着它。当另一个用户请求相同文件时，L1缺失但L2命中，回源次数从N次降为1次。这对于带参数但变化不频繁的API响应尤其有效。
常见的二级缓存拓扑结构
实际部署中，L2 Cache的拓扑有多种选择，不同规模和服务商有不同实现：
区域聚合型
按地理区域（如华东、华北、华南）部署L2节点，该区域内的所有边缘节点共享同一个L2。这种结构最常用，因为网络延迟可控，且能有效应对区域性的热点。
中心辐射型
所有边缘节点共享一个或少量几个全局L2集群（通常部署在一线城市核心数据中心）。适合全球或全国用户分布均匀的场景，但L2的负载较高，距离远时延迟稍大。
多级级联型
在L2之上再增加L3层（如源站前的缓存网关），形成多级缓存链。这种架构通常用于大型视频平台或云服务商，但复杂度高、维护成本大，对于中小网站来说L2已经足够。
开始使用二级子缓存前需要了解的风险
先看关键判断
L2 Cache不是万能药，部署不当可能带来额外问题：
- 缓存一致性变差：多级缓存意味着TTL管理链条更长，如果源站内容更新频繁，你需要精确控制各级缓存的失效策略，否则用户可能看到过期数据。建议使用缓存标签（Cache Tags）或主动失效请求（PURGE）来定向清理。
- L2节点成为新瓶颈：如果L2节点的带宽不够或QPS过高，它自身可能成为瓶颈。需要确保L2集群有足够的吞吐能力，并配置合理的限速和降级策略。
- 冷启动问题：新建的L2缓存为空，最初一段时间所有请求都会穿透到源站，造成短时回源压力。务必提前预热热门资源，或启用渐进式填充。
相关阅读：此处可内链到“CDN L2常见问题”专题。
如何验证你的CDN是否具备L2缓存能力？
验证与回滚
大多数商业CDN服务商（如Cloudflare、Akamai、阿里云CDN、腾讯云CDN等）都支持二级缓存功能，但名称可能不同。你可以通过以下方式确认：
- 查看服务文档中是否有“多级缓存”、“层级缓存”、“二级缓存”、“L2 Cache”等关键词。
- 检查回源日志中的回源IP地址是否指向CDN内部节点（而非源站IP）。如果回源IP是一组固定的CDN内部地址，说明你很可能已经在使用L2缓存。
- 使用自定义请求头（如
X-Cache-Lookup）来判断命中层级。例如某些CDN会返回X-Cache: HIT from L2或X-Cache: HIT from edge的标识。
关联教程：此处可内链到“CDN L2部署与验证”内容。
想继续深入：此处可内链到“CDN L2优化清单”文章。
延伸阅读：此处可内链到“CDN L2配置案例”相关文章。
如果计划自己搭建L2缓存，该怎么做？
我的处理经验
如果你使用的是自建CDN或开源反向代理（如Nginx、Varnish、Squid），也可以手动搭建L2缓存层。以下是基本步骤：
- 部署L2节点：选择1-2个性能较好的服务器（建议大内存+SSD），安装缓存软件（Varnish或Squid），配置为反向代理模式，并将源站地址指向L2节点（而非直接暴露源站）。
- 修改边缘节点配置：将边缘节点的回源地址改为L2节点的内网IP（或低延迟公网IP），并在边缘节点上启用L2上的缓存转储（如
proxy_cache_use_stale updating）。 - 设置缓存策略：在L2节点上设置比边缘节点更长的缓存时间（如边缘TTL=1小时，L2 TTL=24小时），同时针对动态内容配置相应的缓存规则（如忽略Cookie、根据URL参数分组）。
- 监控与调优：使用工具（如Varnishstat、ngx_cache_purge）统计L2层的命中率和回源流量，根据实际情况调整缓存大小和淘汰策略。
注意：如果源站本身有动态内容（如登录态、购物车），请务必在L2层设置合理的缓存黑名单，避免缓存敏感或私有数据。通常只对GET请求的静态资源开启二级缓存，POST和带Cookie的请求直接透传至源站。
进阶阅读：此处可内链到“CDN L2性能优化”指南。
总结
实际操作要点
二级子缓存（L2 Cache）是CDN拓扑中一项成熟且高效的技术，通过引入中间缓存层，将多个边缘节点的回源请求聚合在一起，极大减少了源站带宽消耗。对于中大型网站或流量波动明显的业务，启用L2缓存往往能将回源带宽降低50%-90%，同时还能提升用户访问的稳定性。对于小型网站，如果当前的缓存命中率已经很高（>95%），则L2的收益可能不明显，但仍可作为未来业务增长时的扩容手段。理解并正确使用L2缓存，是优化CDN成本和架构不可绕过的一环。真正做好CDN L2，靠的不是参数堆砌，而是持续验证。
延伸阅读