视频业务中TS切片文件是由直播流或点播文件按固定时长切分出来的传输流片段，通常一旦生成就不会再被修改。这个特性让它可以走CDN长期缓存路线，但真实场景里很多人只给切片设了很短的缓存时间，或者把索引文件和切片用同一套缓存规则，结果边缘节点频繁回源，源站带宽和负载都扛不住。合理的做法是把切片本身当成不变资源，用长缓存加上版本控制手段来管理。
TS切片为何适合长期缓存
TS切片在生成时一般对应固定的时间戳或序列号，内容经过编码后就不会再变化。比如一个直播流在2024-01-01 12:00:00开始的五秒片段，无论后面怎么处理，这个片段的字节内容已经固定。CDN边缘节点如果把它缓存一年，后续所有请求这个片段的用户都能直接命中，不需要回到源站拉数据。这和网页里动态接口完全不同，动态接口每次返回可能不一样，而TS切片是典型的不变量资源。
从缓存命中率角度看，长缓存能显著降低回源率。假设一个热门直播有十万人观看，切片缓存时间只有十分钟，那么源站每十分钟就要被边缘节点重新拉一遍全量切片。如果缓存时间设为三十天，且切片名稳定，那么只有第一次冷启动会回源，之后几乎零回源。我们可以用简单模型估算：切片平均大小一兆，十万人看一小时直播产生七百二十个切片，短缓存下回源流量接近七百二十吉比特，长缓存下仅首次几吉比特。
需要注意的是，长期缓存并不等于无脑设最大年龄。还要配合正确的缓存键和不变文件名。如果每次推流都生成新的临时目录名却不清理，边缘会积攒大量冷文件，占用存储。更好的方式是按频道和日期组织路径，让旧切片自然过期，新切片按名命中。
版本控制在切片重名场景下的落地
很多系统用递增序列号做切片名，如 seq_0001.ts、seq_0002.ts。这在直播时没问题，但点播重转码或剪辑后，新的 seq_0001.ts 内容可能和旧的不同。如果CDN还缓存着旧文件，用户就会看到错误画面。版本控制就是给切片加一个内容相关或发布相关的标识，让不同版本不会互相覆盖。
常用方案有两种。第一种是内容哈希，把切片二进制算一个 sha256 前八位拼到文件名：seq_0001_ab12cd34.ts。只要内容变，哈希就变，CDN自动视为新文件，旧文件靠长缓存自然留存。第二种是发布版本号，比如 v2_seq_0001.ts，由业务在生成时指定。下面代码展示如何用简单脚本给切片附加哈希名：
import hashlib
import os
def rename_ts_with_hash(folder):
for name in os.listdir(folder):
if not name.endswith('.ts'):
continue
path = os.path.join(folder, name)
data = open(path, 'rb').read()
h = hashlib.sha256(data).hexdigest()[:8]
base = name[:-3]
new_name = base + '_' + h + '.ts'
os.rename(path, os.path.join(folder, new_name))
print('rename', name, 'to', new_name)
rename_ts_with_hash('/data/ts_cache')
上面的脚本遍历目录，对每个 TS 文件读取内容计算哈希，把结果拼到文件名里。这样即使原序列号相同，内容不同也会生成不同文件，CDN 上新旧版本互不干扰。缺点是文件名变长，且需要生成端和索引端同步改引用。
索引文件如 m3u8 必须和切片命名保持一致。如果切片用了哈希名，m3u8 里写的也必须是哈希名。索引文件本身不能长缓存，通常设两三秒到一两分钟，保证用户拿到最新列表，而列表指向的 TS 文件走长缓存。这种分层缓存既新鲜又高效。
CDN配置与回源保护的协同设计
在CDN控制台里，一般可以为不同路径配不同缓存规则。我们建议把 *.ts 路径设为缓存一年，并打开「忽略查询字符串」或按固定缓存键，避免相同文件因带不同参数被当成多份。同时开启「回源跟随缓存头」，让源站返回的 Cache-Control 生效。源站对 TS 文件响应头可写 Cache-Control: public, max-age=31536000。
回源保护方面，可在边缘做请求合并，即同一个切片如果同时有很多未命中请求，只回源一次，其余等待结果。另外对源站设限速和连接数上限，防止切片意外短缓存时打挂。下表对比两种配置的差异：
| 配置方式 | 切片缓存时间 | 索引缓存时间 | 回源率估算 | 适用场景 |
|---|---|---|---|---|
| 统一短缓存 | 600秒 | 600秒 | 高，约30% | 测试环境 |
| 切片长缓存加分版本 | 31536000秒 | 5秒 | 低，约1% | 生产直播点播 |
从表里能看出，长缓存加版本控制能把回源率压到极低。实际运维中还要注意切片删除策略，源站定期清旧文件不影响CDN已缓存内容，边缘依据自身存储水位淘汰即可。若业务需要强制换新，比如版权原因，必须改版本号或哈希，不能指望删源站文件就让边缘失效。
最后提一个常见误区：有人用相同文件名覆盖更新切片，却期望CDN马上变新。这违反不变资源假设，会导致部分地区用户看到旧视频。正确做法永远是出新文件、改索引，旧文件靠时间自然退出，这样长期缓存才安全稳定。
CDN_cacheTS_segmentversion_control修改时间：2026-08-18 19:56:16