促销开始后，商品详情、活动页和图片资源可能同时迎来访问高峰。若边缘节点频繁把请求转发到源站，数据库与应用服务会承受重复压力；若缓存规则过于宽松，又可能把不同用户或不同商品的内容混在一起。电商促销期间流量突增的边缘分流策略，重点不是“尽量多缓存”，而是按内容可共享程度分流，并为回源设置明确边界。
先按请求类型划分流量
把入口请求至少分为三类：可公开复用的静态资源、允许短时间共享的商品与活动信息，以及必须实时计算或涉及个人状态的请求。商品图片、样式文件通常适合较长缓存；商品标题、价格和库存则要结合业务更新频率设定较短缓存或单独刷新；购物车、订单提交和账户操作一般应直达应用服务，不应因促销而套用公共页面缓存。
边缘分流可依据路径、请求方法和必要的业务标识配置规则。规则先匹配范围小、风险低的静态资源，再处理商品页等动态内容。对无法明确判断是否可共享的请求，宁可回源，也不要默认进入共享缓存。边缘缓存能减轻重复读取，但不能代替库存扣减、订单校验等源站业务逻辑。
缓存键要覆盖“会改变响应”的因素
缓存键决定哪些请求会命中同一份缓存。商品编号、语言、币种或地区确实会改变页面内容时，应纳入缓存键；追踪参数、无关排序参数等若不会影响响应，可在确认后剔除，避免同一商品被拆成大量低命中率对象。不要把所有查询参数一股脑加入，也不要忽略会影响价格展示的必要条件。
例如，同一商品的详情页若因地区显示不同税费，地区信息就不能被错误合并；而广告来源标记若只用于统计，通常不必造成新的缓存副本。上线前应比较两组条件不同的请求：检查缓存键是否不同、响应是否应相同，并确认缓存失效或更新后不会继续返回旧内容。这一步直接关系到缓存错配风险。
给源站设保护，而不是只扩大边缘缓存
控制回源并发与突发重试
设置回源并发上限、请求超时和排队上限，避免边缘节点在源站变慢时无限堆积请求。对同一热门对象，可采用请求合并，让多个边缘请求等待一次回源结果，而不是同时击穿缓存。源站过载时，优先保留下单校验等关键链路的资源，并对非关键、可延迟更新的内容采取受控降级。
用旧内容兜底要看业务边界
对商品描述、活动说明等允许短暂延迟的数据，可在新缓存刷新失败时短时间提供旧版本；库存、价格和订单状态则要依据业务规则，不能把“返回旧缓存”当作通用降级方案。可用 NGINX 或 Envoy 等代理组件实现路由、限流或超时控制，具体能力取决于部署方式与配置，需在现有架构中验证。
按步骤灰度分流并观察指标
- 建立基线：记录促销前的请求量、源站并发、错误率、响应时间和各类请求的缓存命中情况，按分钟观察高峰变化。
- 先处理低风险流量：优先将图片、脚本等稳定静态资源交由边缘节点服务，再逐步纳入经过验证的商品信息。
- 小比例试切：先让少量流量使用新规则，观察一段完整业务周期；若错误率、源站负载或内容差异异常，立即回退。切流比例和观察时长应依据压测容量、促销节奏及回退速度确定，不宜套用固定数值。
- 扩大前核对：同时检查回源请求数、缓存命中率、超时、限流触发量，以及商品价格、库存等关键字段是否符合源站结果。
- 保留应急开关：预先准备关闭某类缓存、缩小分流范围或切回原路由的操作，并明确值班人员和判断条件。
常见问题
缓存命中率越高越好吗？
不一定。命中率上升若伴随价格或库存展示不一致，说明规则可能过宽。应结合回源压力和业务正确性判断。
活动开始后还能改缓存键吗？
可以，但要谨慎。变更可能造成缓存重新填充和回源增加，宜先小范围验证，并准备回退。
源站已经变慢，应该继续增加分流吗？
不应只扩大分流范围。先限制回源并发，确认哪些内容可安全由边缘返回，再保护下单等关键请求。
如何避免把个性化页面缓存给其他用户？
识别会改变响应的身份或会话条件，对这类页面禁用共享缓存或单独设计隔离规则。最终，电商促销期间流量突增的边缘分流策略应以内容可共享、源站可承受和业务数据正确为共同验收标准。