体育站群CDN加速怎么配？节点选择与缓存规则实战心得

维护体育站群的朋友应该都有同感：平时流量还算平稳，一到比赛日就跟坐过山车似的，凌晨和晚间高峰的并发量能差出七八倍。这种业务形态下，CDN真不是买完带宽就万事大吉，配置上的每个细节都直接关系到源站能不能扛住。我维护几十个体育子站有些年头了，这里把CDN加速配置里踩过的坑和验证过的做法整理一下，包括节点怎么挑、缓存规则怎么写、回源怎么设，都是实际跑过流量检验的。

选节点先看覆盖范围，价格放第二位

体育站群有个很明显的特征：用户地域分布跟赛事热度绑得很紧。欧洲杯、NBA总决赛那阵子，某些省份的访问量说翻几倍就翻几倍。挑CDN节点的时候，我习惯先把子站按主推赛事分类，翻每个站的历史访问日志，圈出访问量前五的省份，再去看CDN服务商在这些区域有没有边缘节点。总节点数看着多没用，节点在西北、用户扎堆华南，延迟该高还是高。

配置的时候，静态资源域名和主站域名我一般分开解析。图片、CSS、JS走专门的CDN域名，主站HTML走另一个，这样缓存时间可以各自独立调。节点调度开启智能路由，让CDN根据实时链路质量自己切节点，比手动指定回源线路靠谱。还有个容易忽略的点：体育站群子域名多，每个子站最好独立绑定加速域名，别所有站共用一个CNAME，不然一个站被攻击，整批站跟着遭殃。

缓存规则按内容类型分层设置

体育站的内容结构其实比较固定：赛事列表页、比分页、新闻详情页、图片和视频封面。这几类内容的更新频率差得远，缓存时间设成一样肯定要出问题。我通常分三档来处理。

静态资源：长缓存配合版本号

图片、字体、JS这类文件，缓存时间直接拉到30天，文件名带上hash或者版本号参数。用户第二次访问基本就不回源了，省下来的带宽相当可观。改版的时候换个文件名就行，不用手动去刷CDN。

列表页和比分页：短缓存加主动刷新

比分页和赛事列表页更新频繁，缓存设60到120秒比较合适。比赛进行中，我会通过CDN服务商的API主动推刷新，比干等缓存过期快得多。这里有个坑得提一下：部分服务商的刷新接口有频率限制，站群子站多的时候要排队提交，所以我把刷新任务做成队列，按赛事优先级依次推。

详情页：边缘缓存配合回源合并

新闻详情页内容不变但访问比较分散，缓存时间放到10分钟没问题。回源策略上开启回源合并，同一时间多个节点回源同一个页面时，源站只处理一次请求。这个功能对体育站群特别管用，赛事结束后大量用户同时点进同一条战报，没开合并的话源站瞬间就被打满。

回源配置的几个实操要点

回源协议我统一走HTTPS，源站配好证书，避免CDN回源时降级。回源超时时间设短一些，3到5秒，超时后CDN直接返回旧缓存或者错误页，别死等源站响应，否则边缘节点会堆积大量挂起连接。源站前面最好再加一层负载均衡，CDN回源地址指向负载均衡而不是单台服务器，某台源站宕机也不影响整体。

体育站群还有个特殊情况：赛事直播期间，部分子站会临时上活动页，流量突增。这种页面我会提前在CDN控制台做好预热，把页面推送到边缘节点，避免开赛瞬间集中回源。预热接口一般按URL批量提交，站群场景下要把子站域名和路径拼对，漏一个斜杠都可能预热失败。

安全防护和日志别省

CDN层开启基础防护，包括CC防护和IP黑名单。体育站群容易被竞争对手或者脚本刷量，比分接口尤其招刷，被刷起来源站数据库压力很大。我在CDN上对接口路径单独设了频率限制，单IP每分钟超过阈值就返回403，规则上线后源站负载降了差不多四成。

日志方面，开启实时日志投递到对象存储，保留30天。排查问题时能快速定位是哪个子站、哪个节点出的异常。有次某个子站的图片全部404，查日志发现是CDN回源路径配错了，十分钟内就修好了。没有日志的话，这种问题得挨个节点试，很耽误事。

整体来看，体育站群的CDN配置没有一劳永逸的方案，赛事周期变化、子站增减都会影响策略。我的习惯是每个季度复盘一次命中率和回源带宽占比，命中率低于85%就回头检查缓存规则，回源带宽突然上涨就查是不是有子站配置漏了。把这些细节盯住，CDN才算真正用起来了。