视频类业务发展到一定规模后，CDN成本会逐渐超过计算和存储成本，成为运维团队最头疼的项目。表面上看，成本升高来自用户播放量增加，但仔细拆解账单会发现，大量长尾视频的缓存命中率极低，每次播放都要从源站拉取，而源站又因为历史原因使用了高性能存储和全量转码，导致回源成本被严重放大。要解决这个问题，不能简单地提高CDN缓存时间或者压缩码率，而是需要从数据生命周期和访问热度入手，建立冷热数据分层机制，并在CDN侧配置对应的降级策略。
冷热数据分层的判定依据与存储方案
冷热数据分层的本质是让访问频率决定资源投入。热数据通常指最近7天内有播放、播放次数超过一定阈值的视频，冷数据则是超过30天无访问或者播放次数极低的内容。中间可以引入温数据概念，避免冷热跳变导致频繁迁移。判定不能只靠单一指标，需要综合播放次数、最近访问时间、视频时长、文件大小等维度，使用加权评分模型。例如一个10秒的短视频和一部2小时的电影，即使播放次数相同，热度表现也可能不同。
存储选型是分层落地的关键。热数据可以放在SSD或高性能对象存储上，温数据使用普通标准存储，冷数据迁往低频或归档存储。以对象存储为例，标准层级每GB单价通常在0.1元到0.2元人民币之间，低频层级可能只有其三到四成，归档层级甚至低到十分之一，但取回需要额外付费且延迟较高。所以迁移之前必须评估取回概率，针对可能突然回热的冷数据，可以保留低分辨率副本在标准层级，原片归档，兼顾成本和可用性。
下面是一个基于Python的冷热判定脚本示例，演示如何根据播放记录计算每个视频的热度标签。
import datetime
from collections import defaultdict
def classify_video(play_records, hot_days=7, hot_count=20, cold_days=30, cold_count=5):
# play_records: list of dict with video_id, play_time
stats = defaultdict(lambda: {'count': 0, 'last_time': None})
now = datetime.datetime.now()
for record in play_records:
vid = record['video_id']
play_time = record['play_time']
stats[vid]['count'] += 1
if stats[vid]['last_time'] is None or play_time > stats[vid]['last_time']:
stats[vid]['last_time'] = play_time
result = {}
for vid, data in stats.items():
days_since_last = (now - data['last_time']).days if data['last_time'] else 999
if data['count'] >= hot_count and days_since_last <= hot_days:
result[vid] = 'hot'
elif data['count'] <= cold_count or days_since_last >= cold_days:
result[vid] = 'cold'
else:
result[vid] = 'warm'
return result
这段代码只适合小规模数据演示。实际工程中视频量级可能达到百万甚至上亿，直接全量加载到内存不现实。通常的做法是把每天的播放日志写入数据仓库，通过Spark或Hive按日批处理，生成冷热标签后写回元数据库，供存储生命周期规则和CDN缓存策略读取。
CDN降级策略的具体实现
分层存储解决的是源站侧的成本问题，但CDN侧如果不配合降级，回源流量依然会把带宽成本推高。降级策略的核心思路是根据数据冷热标签和用户请求特征，差异化分配边缘缓存和回源资源。常见的降级手段包括调整缓存TTL、回源限速、动态转码、预热白名单以及边缘节点淘汰优先级。
缓存TTL是成本控制的第一道开关。热数据可以设置较长的缓存过期时间，例如7天甚至更长，确保边缘节点长期持有热门内容；冷数据则把TTL缩短到1小时甚至不缓存，减少边缘磁盘占用。但完全不缓存会导致每次请求都回源，回源成本可能反而更高，所以需要根据源站存储层级和网络单价计算最优TTL。以低码率冷数据为例，如果回源一次的成本是边缘缓存一天成本的五倍，那么TTL至少应设置为一周才划算。
动态转码和降级输出是更细粒度的压降手段。对于长尾视频，可以在源站只保留高清原片，通过CDN边缘节点按需生成低码率版本，这样用户播放时优先走低码率，只有付费用户或需要高清时才回源拉取原片。Nginx配置中可以通过条件判断请求参数来分流到不同码率的资源。
location /video/ {
# 冷数据回源限速：限制读源站带宽为每秒2MB
limit_rate 2m;
proxy_pass http://origin_storage;
proxy_cache edge_cache;
proxy_cache_valid 200 1h;
proxy_cache_key "$uri";
# 当请求包含low=1参数时，切换到低码率文件
if ($arg_low = "1") {
rewrite ^/video/(.*) /video_low/$1 last;
}
}
预热白名单和边缘淘汰策略也直接影响成本。对于即将上线的热门内容，运营团队可以提前把视频文件推送到CDN边缘节点，避免上线瞬间集中回源导致源站压力过大。而对于长尾冷数据，可以在边缘节点配置最近最少使用（LRU）淘汰策略，优先清理长时间未被访问的对象，把磁盘空间留给高频内容。部分CDN厂商支持通过API动态调整缓存规则，团队可以基于冷热标签自动下发配置。
成本监控与调优方向
分层存储和降级策略上线后，必须用数据说话。核心监控指标包括CDN边缘命中率、回源流量、源站出带宽、存储费用、转码计算费用和用户播放错误率。建议在切换前后各采集至少两周的数据做对比，避免短期波动影响判断。
命中率是最直观的指标。如果降级后命中率没有明显提升，甚至下降，说明缓存TTL设置不合理或者冷热标签判定错误，导致大量本应缓存的温数据被过早淘汰。回源流量则直接关联带宽成本，需要重点关注每天的回源峰值和平均值。存储费用可以通过云平台账单按层级拆分，确认冷数据迁移是否真的降低了存储支出。
下面给出一个从CDN日志计算命中率的Python示例，日志格式可以按实际调整。
import re
def calc_hit_rate(log_lines):
total = 0
hit = 0
for line in log_lines:
# 假设日志格式中第9列是缓存状态：HIT/MISS
parts = re.split(r'\s+', line)
if len(parts) > 8:
status = parts[8]
total += 1
if status == 'HIT':
hit += 1
return hit / total if total > 0 else 0.0
调优是一个持续迭代的过程。如果发现回源流量没有显著下降，可以检查冷数据判定阈值是否过松，导致大量温数据被错误降级；或者降级策略过激进，用户频繁切换清晰度反而增加了转码计算成本。此时需要把阈值和降级参数逐步回调，同时可以考虑按用户类型区分策略，例如对付费用户保持高清回源，对免费用户执行降级，以控制整体成本。
最后要强调，视频CDN成本控制不是一次性工程，内容热度会随时间和运营活动动态变化。冷热标签需要定期重算，存储迁移可以利用生命周期规则自动执行，CDN降级策略也应支持灰度发布和快速回滚，确保在成本优化的同时不损害播放体验。