TG咨询电商大促时，商品详情页、活动会场和图片资源会在短时间内集中访问，但库存、价格、优惠券和订单状态又必须保持较快更新。合理的CDN与源站配合，应当把“能缓存的内容尽量留在边缘节点”，把“必须实时读取的数据”交给应用和数据库处理，同时限制突发流量对源站的冲击。
下面按实施难度和适用场景，整理5种常见方案。企业可以单独采用，也可以组合使用。
一、静态资源长缓存，动态接口绕过缓存
这是最基础、适用范围最广的方案。商品图片、字体、CSS、JavaScript和带版本号的活动素材通常适合缓存；购物车、登录、下单、库存查询和个性化推荐接口则应根据业务规则回源。
实施步骤
- 按路径或文件扩展名划分资源，例如将图片、视频和带版本号的脚本设置为缓存对象。
- 为商品详情接口、价格接口、库存接口设置较短缓存时间，或者直接设置为不缓存。
- 检查请求中是否包含登录状态、购物车标识或鉴权信息，避免把用户专属内容错误共享给其他访客。
- 在测试环境验证缓存命中、未命中、刷新和回源状态，再逐步扩大到大促流量。
静态资源缓存时间可以从数小时到数天不等，具体取决于文件是否采用内容指纹命名。优点是改造成本低、见效快；缺点是规则过于宽松时可能展示旧价格，过于严格又会增加源站请求。
二、版本化发布配合定向刷新
当活动页频繁修改时，与其依赖全站刷新，不如给资源和页面建立版本号。例如将活动脚本从 promo.js 改为带构建版本的文件名，发布新版本后让页面引用新地址。旧资源继续由边缘节点服务，新资源自然触发首次回源。
商品价格、促销标签等数据不宜只依靠静态页面缓存。可以把页面骨架与实时数据拆开：页面主体设置较长缓存，价格和库存由前端调用独立接口获取。价格调整后，只刷新相关接口或指定商品页面，而不是清空全部缓存。
这种CDN与源站配合方式适合内容发布频繁、商品数量较多的商城。它能减少批量刷新造成的回源尖峰，但需要构建流程、缓存规则和发布系统保持一致。若页面引用仍指向旧版本，单纯刷新缓存并不能解决代码未更新的问题。
三、设置回源保护层，合并重复请求
大促开始后的热门商品可能在短时间内被大量访问。多个边缘节点同时未命中时，如果每个节点都直接请求源站，源站会收到大量相同请求。此时可以在边缘节点与源站之间增加区域缓存、缓存代理或回源汇聚层，让相同资源的请求尽量合并。
适用与操作重点
- 先选出商品图、活动页、说明文档等可重复缓存的对象，避免把下单和库存接口纳入合并范围。
- 为回源层配置较短的连接超时和合理的并发上限，防止异常请求长期占用资源。
- 让回源层保留必要的请求头，并确认源站能够识别正确的域名和路径。
- 通过监控观察回源请求数、响应时间、错误率和连接数，逐步调节缓存时间。
该方案适合访问集中在少数爆款商品的场景，通常能降低源站重复读取压力。它的代价是架构更复杂，新增一层后需要同时考虑缓存失效、节点故障和日志排查。
四、预热重点页面，错峰释放源站压力
对于已知的大促开始时间，可以提前准备商品详情页、活动首页和分类页的缓存。预热不是把所有URL一次性发送出去，而是按照访问预测、商品重要程度和源站承载能力分批执行。
- 从商品系统导出重点页面地址，去除重复、失效和不允许公开访问的链接。
- 在正式活动前数小时开始分批请求，先预热活动入口，再预热重点商品和图片资源。
- 观察源站CPU、数据库连接数、带宽和响应时间，若指标持续升高就降低预热并发。
- 活动前再次核对价格、库存和优惠规则，必要时只刷新涉及变化的页面。
预热适合内容相对稳定、活动时间明确的商城。它可以降低第一波访问的冷启动压力，但不能替代实时库存控制，也不能保证所有用户请求都命中缓存。预热请求的数量和速度必须服从源站容量。
五、多源站与故障降级组合
当单一源站难以承受大促流量时，可以将应用部署到多个可用区或多个源站节点，再通过负载均衡分配请求。静态资源和读请求可以使用更多节点，写入订单、支付和库存扣减仍需遵循应用的一致性设计。
建议的降级顺序
- 优先保障登录、购物车、下单和支付回调等核心链路。
- 当源站响应变慢时，暂停低优先级推荐、评论加载和非必要统计请求。
- 对商品详情页保留最近可用内容，并明确标注价格和库存需以结算页为准。
- 当某个源站节点异常时，将新请求切换到健康节点，同时保留告警和人工确认流程。
多源站方案的优点是容量和容灾能力更强，缺点是发布、会话、数据库读写和日志系统都需要统一管理。若各节点版本不一致，可能出现页面内容不相同，因此上线前应进行配置和数据一致性检查。
如何选择方案
小型商城可以先采用“静态长缓存加动态接口绕过缓存”，再补充版本化发布；访问集中在爆款商品时，优先增加回源保护和重点预热；拥有多个应用节点或跨地域业务时，再考虑多源站和故障降级。无论采用哪种组合，都应提前压测登录、详情、库存、下单和支付等关键路径，而不是只测试首页打开速度。
大促前还应建立缓存命中率、回源请求数、源站响应时间、错误率、数据库连接数和订单接口成功率的监控面板。只有把缓存规则、应用限流和故障处理流程同时验证，CDN与源站配合才能真正转化为稳定性，而不是简单地把流量转发到另一个地址。
常见问题
1. 商品详情页能不能全部缓存？
可以缓存相对稳定的页面结构，但价格、库存、用户专属优惠等数据应单独获取或设置较短缓存时间，不能只看页面是否能够打开。
2. 缓存时间越长越好吗？
不是。图片和带版本号的资源可以较长时间缓存；价格、库存和活动规则变化频繁，应缩短缓存时间或采用定向刷新。
3. 为什么预热后仍然会回源？
可能是预热地址与用户实际请求地址不同，也可能存在查询参数、请求头、缓存键或区域差异。应从缓存键和命中日志逐项核对。
4. 多源站能否直接解决数据库压力？
不能。多源站主要分散应用请求，数据库写入、库存扣减和订单事务仍需要独立扩展与一致性控制。
总结来看，电商大促中的CDN与源站配合应从内容分类开始，再结合版本发布、回源保护、预热和多源站策略逐步加强。先保护源站，再优化命中率，通常比盲目延长缓存时间更稳妥。
