CDN缓存污染前端监控：RUM与拨测的缓存态对账与根因排查

背景

我们使用CloudFront+Lambda@Edge架构，发现前端监控数据与CDN日志存在系统性偏差：

• RUM显示98%请求FCP<1.2s，但CDN日志显示3.2%请求回源耗时>2s
• 拨测节点显示「缓存命中率97%」，但故障时拨测永远显示200
• 错误监控显示「资源加载失败率0.5%」，实际CDN 5xx率是1.8%

现象

1. 监控信号失真：

   • 用户侧RUM显示「缓存命中」，但CDN日志显示「回源失败」
   • 错误上报仅含net::ERR_*，缺失X-Cache: MISS等缓存态信号

2. 对账困难：

   • 无法用transferSize===0区分缓存命中/未命中
   • CDN自定义头字段不统一，部分场景浏览器不可达

3. 故障盲区：

   • CDN节点故障切换、回源抖动等问题被拨测完全遗漏
   • 用户侧「失败」在服务端视角根本不存在

已尝试的排查与结果

• 客户端信号：抓取performance.getEntriesByType('resource')的transferSize，但发现3.7%请求该字段为0却存在回源日志
• 响应头解析：尝试解析X-Cache字段，但CloudFront与AWS API Gateway的头字段格式差异导致误判
• CDN日志对账：每周比对CDN命中率与RUM缓存命中率，发现偏差持续存在
• 拨测改造：尝试让拨测节点强制Cache-Control: no-cache，但牺牲了故障可观测性

期望得到的答案形态

1. 对账口径：

   • 有哪些日志字段能准确标识缓存态？（如Age头、Via头、Surrogate-Capability等）
   • 如何用SQL/ELK实现CDN日志与前端监控的自动对账？

2. 服务端解决方案：

   • 除了Lambda@Edge修改Cache-Control，有没有零改造方案？
   • 如何让拨测节点主动制造「缓存命中/未命中」差异？

3. 量化overlap：

   • 有可复现的公式计算「超时请求中服务端成功比例」吗？
   • 如何用分位数+抖动阈值动态调整前端timeout？

4. 幂等处理：

   • 重复领取这类场景，前端幂等/服务端幂等/业务层幂等各有什么优劣？

欢迎贴具体配置（如CloudFront缓存策略）、日志样例（含X-Cache/Age字段）、对账SQL——细节越多越能对上。