TG咨询CDN与源站配合的重点，不是单独提高缓存命中率，而是让请求分类、回源路径、源站容量和故障策略彼此匹配。静态文件适合尽量在边缘节点完成响应，商品库存、登录状态和订单提交等动态请求，则应通过稳定的应用集群访问数据库或内部服务。
先按请求类型设计回源边界
建议先把业务请求分为三类：可长期缓存的静态资源、可短时间缓存的半动态内容，以及必须实时处理的动态操作。图片、字体、安装包和带版本号的CSS、JavaScript文件，通常适合设置较长缓存时间；首页、榜单或地区配置等内容，可以采用短缓存并配合主动刷新；支付、下单、用户资料和带身份信息的接口，则应默认不缓存响应正文。
| 请求类型 | 适合的回源方式 | 主要风险 |
|---|---|---|
| 图片、视频、安装包 | 边缘缓存，未命中时回源对象存储 | 大文件集中回源、带宽突增 |
| 文章页、活动页 | 短时缓存或按标签刷新 | 更新延迟、缓存内容不一致 |
| 下单、支付、个人中心 | 直接进入应用集群 | 重复提交、会话和权限错误 |
缓存键也要与业务规则一致。语言、地区、设备类型确实影响页面内容时，才将这些字段纳入缓存键；无关参数应在边缘侧清理，否则同一资源可能产生大量低命中率副本。含有用户标识、Authorization头或私人数据的响应，不应因配置疏漏进入公共缓存。
用分层回源减少源站重复工作
设置回源集群与保护层
当多个边缘节点同时访问同一热门资源时，可在靠近源站的位置设置回源汇聚层。它可以由Varnish、反向代理集群或云厂商提供的源站保护能力承担，作用是把多个边缘请求合并为较少的源站请求。这里的关键不是增加一层设备，而是避免突发流量直接打到应用服务器。
大文件宜放入对象存储，例如以MinIO或兼容S3接口的存储作为源站资源池，再由应用服务负责鉴权和生成资源地址。这样能把文件传输与业务计算分开，避免图片下载占用应用服务器连接数。资源上传、转码完成后，应先写入存储，再通过缓存刷新或版本化文件名让边缘节点获得新内容。
为缓存击穿和回源风暴预留规则
- 为热门资源设置合理的基础缓存时间，常见范围可以从数分钟到数小时，具体取决于内容更新频率和一致性要求。
- 启用请求合并或单飞机制，让同一资源在失效瞬间只由一个请求回源，其余请求等待结果或读取旧内容。
- 对短暂故障允许返回尚未过期但仍可接受的旧内容；涉及库存、价格和权限的内容不采用这种兜底。
- 给源站设置并发连接、请求速率和超时时间上限，超过阈值时返回明确的限流结果，而不是让连接无限排队。
源站架构要与回源流量相适应
源站不宜只有一台承担全部职责的服务器。较稳妥的拆分方式是：边缘回源进入负载均衡，再分发到无状态应用实例；应用实例访问Redis等缓存系统和数据库；图片、视频等大文件独立存储。应用实例可以部署在Kubernetes中，但是否使用容器应由发布频率、运维能力和流量波动决定，不能把容器本身当作高可用方案。
对于数据库密集型业务，先区分读流量和写流量。可重复读取的数据由缓存承接，允许短暂延迟的查询可以使用只读副本；订单、库存扣减等写操作必须经过主写路径并具备幂等控制。CDN只能减少到达源站的请求量，不能修复数据库锁等待、慢查询或应用线程池不足。
一套可执行的协同优化流程
- 统计近一段时间的请求路径，分别记录命中、回源、错误、响应时间和响应体大小，按URL类别而不是只看总流量分析。
- 为每类URL确定缓存资格、缓存时间、刷新方式和是否允许旧内容兜底，并把规则写入配置管理系统。
- 将静态文件迁移到独立存储，应用源站只保留必要的鉴权、元数据和动态接口。
- 在测试环境模拟缓存全部失效、单个源站不可用和突发热门资源三种情况，观察应用并发、数据库连接和队列长度。
- 上线后同时监控边缘命中率、回源请求数、源站5xx比例、回源延迟、数据库连接使用率和缓存刷新失败率。
优化时不要只追求更高命中率。命中率上升但缓存键错误，可能把不应共享的内容返回给其他用户；回源次数下降但缓存时间过长，也可能让价格或活动状态滞后。更有价值的目标是让静态请求少回源、动态请求可控回源、源站故障时影响范围可预测。
常见问题
1. 所有页面都放进CDN缓存是否更省源站资源？
不是。公共、可接受延迟的内容适合缓存；用户专属和实时交易内容应绕过公共缓存，否则会产生数据泄露或业务状态错误。
2. 源站只有一台服务器，先优化哪里？
先把静态资源独立出去，再限制大文件和异常请求的回源并发，同时建立备份和恢复方案。之后再拆分应用、存储和数据库，避免一次改动过大。
3. 缓存刷新和缩短缓存时间怎么选？
更新可预测、需要快速生效的内容适合版本化或主动刷新；更新不规律且允许延迟的内容可使用较长缓存。频繁刷新会增加边缘和源站压力。
4. 如何判断问题在CDN还是源站？
对比边缘命中请求与回源请求的延迟、状态码和响应体大小。只有回源链路异常时，重点检查源站连接、应用、数据库和存储；两者都异常时，再检查域名解析、边缘配置或网络路径。
最终，CDN与源站配合应形成明确的流量分工：边缘处理可复用内容，回源层合并重复请求，应用集群处理业务逻辑，存储和数据库承担各自擅长的工作。按这个边界持续验证，才能在流量增长和局部故障时保持可控。
