核心是系统性变更TTL值，采集回源与总请求数并绘制回源率变化曲线；需通过Nginx日志识别MISS/EXPIRED等回源状态，分组灰度测试不同TTL，分析初始陡降、平台稳定、周期脉冲等波动形态，并用X-Cache-Status与后端日志交叉验证。
要测试不同缓存有效期（TTL）设置下的回源率变化曲线，核心是**在可控条件下系统性地变更 TTL 值，采集对应窗口内的回源请求数与总请求数，计算并绘制回源率（%）随 TTL 变化的趋势图**。这不是单次验证，而是一组对比实验，需排除干扰、确保数据可比。
明确回源率定义与采集方式
回源率 = （回源请求次数 ÷ 总请求次数） × 100%，其中“回源请求”指 Nginx 实际向后端服务器发起的请求（非缓存直接响应）。关键在于准确识别和计数：
- 在 Nginx 配置中启用日志记录 upstream 状态：添加 log_format cache_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_cache_status $upstream_response_time';
- 通过 $upstream_cache_status 字段区分：MISS / EXPIRED / STALE / UPDATING 属于回源行为；HIT / REVALIDATED（304）不计入回源
- 用脚本（如 awk + grep）从 access.log 中统计每小时/每5分钟的 HIT 和非-HIT 次数，自动算出回源率
设计 TTL 对照实验组
避免一次性全量切换，采用分组灰度或时间分片方式，让每组 TTL 设置独立运行足够时长（建议 ≥ 3 个完整 TTL 周期），以覆盖冷启动、稳定命中、集中过期等阶段：
- 准备 5 组配置：TTL 分别设为 30s、2m、10m、30m、2h，每组对应一个独立 location 或 proxy_cache_key 前缀（如 /api/data?t=30s）
- 使用相同压测脚本（如 wrk -t4 -c100 -d300s）对每组路径发起恒定并发请求，持续 10 分钟以上
- 确保测试期间无 PURGE、手动清理、后端主动返回 no-cache，且后端响应头含一致的 Last-Modified/ETag
绘制回源率变化曲线的关键观察点
不是只看最终平均值，要分析时间维度上的波动形态：
- 初始陡降段：前 1–2 个 TTL 内，回源率从 100% 快速下降，反映缓存填充速度
- 平台稳定区：TTL 超过请求频率倒数后，回源率趋稳——例如 QPS=50，TTL=30s 时理论最小回源率≈1/(50×30)=0.067%，实际受分布影响略高
- 周期性脉冲峰：当 TTL 较短（如 30s）且请求均匀时，每 30 秒左右出现一次回源小高峰，体现“集体过期”现象
- 长 TTL 下的缓慢爬升：TTL > 数小时后，回源率不再明显下降，反而可能因后端内容更新、客户端强制刷新等引入额外回源
结合 X-Cache-Status 与后端日志交叉验证
仅靠 Nginx 日志可能漏判某些场景，需多源印证：
- 开启 add_header X-Cache-Status $upstream_cache_status;，用 curl 或浏览器批量抓取响应头，统计各状态码占比
- 同步检查后端 access.log：过滤同一时间段内目标接口的访问 IP 和时间戳，确认其与 Nginx 日志中标记为 MISS/EXPIRED 的请求严格对应
- 若发现某 TTL 下回源率异常偏高（如 30m TTL 仍达 40%），检查是否因后端返回了 Cache-Control: max-age=0 或 Vary 头不一致导致缓存无法复用
