CDN利用率是指内容分发网络在实际运行中，边缘节点承接的用户请求比例与节点带宽资源的饱和程度之间的综合表现。很多团队只盯着缓存命中率，却忽略了回源收敛和节点负载均衡，导致账面上的命中率不错，但整体资源使用效率依然低下。要理解利用率，必须把它拆成请求层、带宽层和节点层三个维度分别观测。
请求层利用率：缓存命中与回源收敛
请求层利用率最直观的指标是缓存命中率，也就是边缘节点直接返回给用户、无需回源的请求占比。命中率高说明资源复用好，但如果每次上线都给静态文件加随机哈希且未做缓存键规整，边缘节点会把不同URL当作不同资源，缓存空间被碎片化占用，命中率自然上不去。除了命中率，还要看回源收敛比，即多个边缘节点对同一源站资源的回源请求是否被合并。缺乏合并机制时，一百个节点同时失效就会向源站打一百次相同请求。
实践中可以用如下简单配置统一缓存键，避免查询参数干扰：
# 在CDN边缘或源站反代层忽略无关参数
location /static/ {
proxy_cache_key $scheme$host$uri;
proxy_ignore_headers Set-Cookie;
expires 30d;
}
上面的配置把缓存键固定在协议、域名和路径上，去掉了版本查询串造成的差异。同时设置较长过期时间，让边缘节点在多数情况下直接命中。回源收敛则依赖CDN厂商的锁机制或源站侧的请求合并中间件，当同一资源多个回源同时到达时，只放行一个真实回源，其余等待结果共享。这样请求层利用率才能从表面命中走向真实节约。
带宽层利用率：节点吞吐与峰值削峰
带宽层利用率关注边缘节点出口带宽是否被有效填满，以及源站出网流量是否因回源被放大。如果节点带宽空闲但回源流量巨大，说明调度策略有问题，用户被分配到离源站近却带宽闲置的节点，而不是离用户近的饱和节点。带宽利用率低还会让单价更高的动态加速资源被浪费在静态文件上。
通过按区域统计节点带宽峰值，可以发现某些热点地区节点长期百分之九十饱和，而冷门地区仅百分之二十。此时需要调度系统把冷门地区的部分 DNS 解析权重调低，并开启就近回源与分层回源。下面是一个用脚本采集节点带宽的简单示例：
import requests
def get_node_bandwidth(node_api):
# node_api 为边缘节点上报接口
resp = requests.get(node_api, timeout=3)
data = resp.json()
used = data.get('bandwidth_used_mbps', 0)
total = data.get('bandwidth_total_mbps', 1)
return used / total
if __name__ == '__main__':
ratio = get_node_bandwidth('https://ipipp.com/api/node1')
print('带宽利用率: %.2f' % ratio)
采集后把比率低于阈值的节点标记为可降权，结合业务峰值预测做弹性调度。带宽层利用率提升的核心在于让贵买的带宽真正承载用户流量，而不是在回源链路中空转。当源站出网带宽随回源合并下降，整体 CDN 账单里的隐藏损耗也就被挤掉了。
节点层利用率：负载均衡与健康检查
节点层利用率衡量单台边缘服务器的 CPU、连接数、磁盘缓存占用是否均衡。不少故障源于某节点健康检查迟钝，流量持续灌入已过载机器，周边节点却很闲，整体利用率曲线呈现锯齿状。此时应配置主动探测，不只看 ICMP，还要模拟 HTTP 请求测量响应延迟与错误率。
以边缘调度配置为例，可定义健康检查与权重浮动：
{
"health_check": {
"path": "/healthz",
"interval": 5,
"timeout": 2,
"unhealthy_threshold": 3
},
"load_balance": {
"policy": "least_connections",
"cooldown": 30
}
}
上述策略让调度器优先选连接最少的节点，并在节点连续三次不健康后摘流三十秒。节点层利用率稳定后，请求不会再扎堆导致局部缓存淘汰加剧。把请求层、带宽层、节点层三张指标图叠加，就能算出综合 CDN 利用率：综合值等于命中率乘节点健康度乘带宽填充系数。只有三者协同优化，利用率才会从纸面概念变成可压缩成本的实际抓手。