当前位置: 首页 > article >正文

【Varnish】:解决 Varnish 7.6 CDN 静态资源缓存失效问题

项目场景:

在一个使用Varnish作为反向代理的Web应用中,我们依赖CDN(内容分发网络)来缓存静态资源(如图片、CSS、JavaScript文件等),以提高全球用户的访问速度并减轻源站服务器的负载。然而,在实际运行中,我们遇到了一个问题:CDN缓存的静态资源全部一直回源,导致源站服务器负载过高,响应时间延长,用户体验下降。

问题描述:

症状表现

  • 高源站流量: 监控数据显示源站接收到大量本应由CDN处理的请求。
  • 低缓存命中率: CDN平台中显示静态资源的缓存命中率远低于预期。
  • 响应时间延长: 用户体验到比预期更长的页面加载时间。
  • Via 头部异常: 在响应头中发现了额外的 Via 信息,例如 1.1 yjcm-varnish-0 (Varnish/7.6), cache14.l2et135-6[2,0],这可能是导致CDN失效的原因之一。

产生影响

这些症状直接影响了用户体验和网站性能,增加了服务器负载,当时LB带宽几乎要达到上限。随着系统响应时间逐渐变慢,用户体验急剧下降。因此,解决这个问题对于提升网站的整体性能至关重要。

原因分析:

经过详细的日志分析和技术排查,我们确定以下因素可能导致了上述问题:

1. Via 头部的影响:

  • 标准的 Via 响应头用于标识请求经过的代理服务器链。如果Varnish保留或添加了这个头部,某些CDN可能会误判请求路径,进而影响缓存决策。
  • 特别是当 Via 头部包含多个代理服务器的信息时,可能会使CDN认为每个请求都是唯一的,从而阻止了缓存的有效利用。

2. 自定义VCL逻辑:

  • 如果Varnish配置中有特定的逻辑来决定何时缓存内容或如何处理请求,这些逻辑可能会与CDN的预期行为相冲突,导致缓存策略不再适用。

3. Cookie处理:

  • 默认情况下,如果请求包含 Cookie 头部,Varnish通常不会缓存该请求。这可能导致静态资源因为会话信息而被视为独特的,从而绕过了缓存。

4. 缓存控制头部不一致:

  • Varnish可能修改了来自后端服务器或CDN的关键HTTP头部信息(如 Cache-Control, Expires),导致CDN认为这些资源不应该被缓存。

解决方案:

为了解决这些问题,我们采取了一系列措施,确保Varnish与CDN之间顺畅协作,最大化缓存效率并提升整体网站性能。同时,我们也针对系统性能进行了优化,以改善响应时间。

1. 修改 vcl_deliver 子程序

通过调整 vcl_deliver 子程序,可以实现更清晰的缓存状态指示,并避免不必要的头部冲突:

# 交付子程序 (vcl_deliver)
sub vcl_deliver {
    # 显示缓存命中/未命中信息
    # 这个逻辑用于在响应头中添加一个自定义的头部 X-Varnish-Cache,
    # 以便后续可以通过这个头部判断请求是否被缓存命中。
    if (obj.hits > 0) {
        set resp.http.X-Varnish-Cache = "hit";  # 如果缓存命中(即该对象已被缓存并再次访问),则设置 X-Varnish-Cache 为 hit
    } else {
        set resp.http.X-Varnish-Cache = "miss";  # 如果缓存未命中(即该对象是第一次访问或缓存已过期),则设置 X-Varnish-Cache 为 miss
    }

    # 将 Via 头的内容复制到 X-Varnish-Via 头
    # Via 是一个标准的HTTP头部,用来标识请求经过的代理服务器链。
    # 为了避免影响CDN对缓存决策的理解,我们将原始的 Via 头内容复制到一个新的头部 X-Varnish-Via,
    # 并删除原来的 Via 头,确保CDN不会因为额外的代理信息而误判请求路径。
    if (resp.http.Via) {
        set resp.http.X-Varnish-Via = resp.http.Via;  # 将原始 Via 头内容复制到新的 X-Varnish-Via 头
        unset resp.http.Via;  # 删除原来的 Via 头,避免干扰CDN的缓存决策
    }
}

解释:

  • 显示缓存状态: 通过添加 X-Varnish-Cache 响应头,提供了关于缓存命中的明确指示,这对于调试和理解缓存行为非常有用。
  • 清理 Via 头: Via 头通常用于标识请求经过的代理服务器链。将其内容复制到 X-Varnish-Via 并删除原始 Via 头,可以帮助减少混淆,并确保CDN能够正确解析响应。

2. 同步缓存控制头部

确保Varnish不会覆盖或修改来自后端服务器或CDN的关键缓存控制头部,如 Cache-Control 和 Expires。可以通过以下方式同步这些头部:

sub vcl_backend_response {
    # 同步 Cache-Control 和 Expires 头部
    if (beresp.http.Cache-Control && beresp.http.Expires) {
        set beresp.http.Cache-Control = beresp.http.Cache-Control;
        set beresp.http.Expires = beresp.http.Expires;
    }
}

3. 确保缓存一致性

确保Varnish和CDN之间的缓存策略一致,特别是对于静态资源的缓存控制头部:

  • 标准化响应头部: 保持所有响应头部的一致性,有助于维持整个系统的稳定性和性能。
  • 检查缓存标签: 确认Varnish和CDN都支持并正确处理缓存标签(如 ETag, Last-Modified)。

4. 测试与验证

  • 测试清除效果: 在非生产环境中进行更改前,先在一个小范围内测试,确保不会对用户体验产生负面影响。
  • 监控性能变化: 使用性能监控工具来跟踪实施更改后的性能指标,确保问题得到解决且没有引入新的问题。

结论

通过精心调整Varnish配置并遵循最佳实践,我们可以确保Varnish与CDN之间顺畅协作,最大化缓存效率并提升整体网站性能。希望这篇文章能为你和其他开发者提供有价值的参考,帮助解决类似的缓存失效问题。如果有更多复杂的需求或疑问,建议参考官方文档或寻求专业支持。


http://www.kler.cn/a/503698.html

相关文章:

  • 神经网络初始化 (init) 介绍
  • 你喜欢用什么编辑器?
  • Java中的动态代理是什么?如何实现?
  • Spark vs Flink分布式数据处理框架的全面对比与应用场景解析
  • P1图文解析:初识算法和数据结构
  • [Deep Learning] Anaconda+CUDA+CuDNN+Pytorch(GPU)环境配置-2025
  • day09_kafka高级
  • 《蜜蜂路线》
  • JavaWeb开发 - Filter过滤器详解
  • 【OJ刷题】同向双指针问题3
  • 【机器学习】P1 机器学习绪论
  • vite之---为什么选vite
  • seleniun 自动化程序,python编程 我监控 chrome debug数据后 ,怎么获取控制台的信息呢
  • 使用Docker模拟PX4固件的无人机用于辅助地面站开发
  • MCP Server开发的入门教程(python和pip)
  • 服务器宕机原因?该怎么处理?
  • AOSP 14及以上userdebug无法调试的问题
  • wireshark开启对https密文抓包
  • c语言注意事项(不断完善版)
  • 大师课程:专业角色AE+AI动画动态设计关键帧学院视频课程 Key Frame Academy – Character Animation Launchpad