边缘加速
  • 站点加速
    • 概述
    • Quickly Import and Export Site Configuration
    • 访问控制
      • Token 鉴权
    • 智能加速
    • 文件优化
      • 智能压缩
    • 网络优化
      • HTTP/2
      • HTTP/3(QUIC)
        • 概述
        • 启用 HTTP/3
        • QUIC SDK
          • SDK 概览
          • SDK 下载和集成指引
          • 代码示例
            • Android
            • iOS
          • API 文档
            • Android
            • iOS
      • IPv6 访问
      • 最大上传大小
      • WebSocket
      • 携带客户端 IP 头部回源
      • 携带客户端 IP 地理位置头部回源
      • 开启 gRPC
    • URL 重写
      • 访问 URL 重定向
      • 回源 URL 重写
    • 修改头部
      • 修改 HTTP 节点响应头
      • 修改 HTTP 回源请求头
    • 自定义错误页面
    • 请求与响应行为
      • 请求处理顺序
      • EdgeOne 默认 HTTP 回源请求头
      • EdgeOne 默认 HTTP 响应头
    • Media Services
      • Audio and Video Pre-pulling
      • Just-in-Time Image Processing
      • Just-in-Time Media Processing
      • VOD Media Origin
  • 四层代理
    • 概述
    • 新建四层代理实例
    • 修改四层代理实例配置
    • 停用/删除四层代理实例
    • 批量配置转发规则
    • 获取客户端真实IP
      • 通过 TOA 获取 TCP 协议客户端真实 IP
      • 通过 Proxy Protocol V1/V2 协议获取客户端真实 IP
        • 概述
        • 方式一:通过 Nginx 获取客户端真实 IP
        • 方式二:在业务服务器解析客户端真实 IP
        • Proxy Protocol V1/V2 获取的客户端真实 IP 格式
      • 通过 SPP 协议传递客户端真实 IP
  • 边缘 DNS
    • 托管域名 DNS 解析
      • 修改 DNS 服务器
      • 配置域名 DNS 解析记录
      • DNS 高级配置
    • 接入加速域名
      • 添加加速域名
      • 站点/域名归属权验证
      • 修改 CNAME 解析
    • 别称域名
      • 概述
      • 配置指南
      • 通过别称域名批量接入 SaaS 建站域名
      • 别称域名实现业务的容灾
    • 流量调度
      • 流量调度管理
    • 源站配置
      • 回源配置
        • 配置回源 HTTPS
        • Host Header 重写
        • 回源请求参数设置
        • 回源跟随重定向
        • HTTP/2 回源
        • 分片回源
      • 负载均衡
        • 概述
        • 快速创建负载均衡实例
        • 健康检查策略介绍
        • 查看源站健康状态
        • 相关参考
          • 负载均衡相关概念
          • 请求重试策略介绍
      • 源站组操作指引
      • 相关参考
        • 旧版源站组兼容相关问题
      • 获取 EdgeOne 回源节点 IP
  • 边缘缓存
    • 概述
    • EdgeOne 缓存规则介绍
      • EdgeOne 内容缓存规则
      • 缓存键(Cache Key)介绍
      • Vary 特性
    • 缓存配置
      • 自定义 Cache Key
      • 节点缓存 TTL
      • 状态码缓存 TTL
      • 浏览器缓存 TTL
      • 离线缓存
      • 缓存预刷新
    • 清除和预热缓存
      • 清除缓存
      • 预热缓存
    • 如何提高 EdgeOne 的缓存命中率
  • 规则引擎
    • 概述
    • 规则引擎支持的匹配类型与操作
    • 规则管理
    • 变量

缓存键(Cache Key)介绍

什么是缓存键(Cache Key)

缓存键(Cache Key)用于决定用户访问的文件资源是否命中 EdgeOne 边缘缓存内容,是节点内缓存资源的唯一标识。缓存命中可以帮助您的站点:
减少回源请求量,降低源站带宽消耗。
提高用户的访问请求速度。
缓存键的工作原理如下所示:
当文件被缓存到 EdgeOne 边缘节点中时,节点将根据缓存键规则来为文件生成一个对应的缓存键标识,默认情况下,缓存键通过客户端请求 URL 和查询字符串计算得出。当有其它客户端向该边缘节点发起 HTTP 请求时,节点将根据 Cache Key 的计算规则,来比对该 HTTP 请求与节点内所有缓存资源的缓存键(Cache Key)是否一致,如果一致时,则将对应的缓存资源直接响应给该客户端,即缓存命中。


缓存键(Cache Key)的作用场景

缓存键(Cache Key)用于 EdgeOne 节点为不同版本的文件建立多版本缓存内容,即使客户端通过同一路径请求,也可以通过缓存键(Cache Key)的计算规则来正确响应用户文件。

您可以通过以下场景示例来了解如何正确配置 Cache Key 来帮助您正确匹配请求的缓存文件,同时降低请求的回源率。
例如:用户 A 和用户 B 分别有以下请求:
请求 A:https://www.example.com/Image/test.jpg?version=1&time=1651752743
请求 B:https://www.example.com/Image/test.jpg?version=2&time=1651758319
场景一:用户访问的文件路径完全相同,但是根据查询字符串内携带的version参数不同,将会有版本的区分,以上请求分别为两张不同的图片,此时应在 Cache Key 中保留会影响文件版本的参数version,来保证节点能正确缓存并响应对应的文件内容。
场景二:用户访问的 URL 中查询字符串的内容完全不影响文件内容,以上请求所对应的文件一致,不影响文件版本,此时应该在 Cache Key 计算中忽略所有查询字符串,来提高文件在节点内的命中率,减少请求回源。

允许自定义的 Cache Key 内容及生效规则

EdgeOne 允许用户自定义 Cache Key 规则,支持配置查询字符串、HTTP 请求头或者 cookie 进行区分缓存。您可以通过 自定义 Cache Key 来了解如何配置自定义的 Cache Key 规则。
注意:
1. 缓存键计算以客户端向节点发起的 HTTP 请求内容为准,回源 URL 改写、回源跟随重定向、回源 HTTP 请求头、访问 URL 重写均不影响缓存键的计算。
2. 当在 EdgeOne 内配置了 Token 鉴权时,鉴权内容不会参与至缓存键计算中。
3. 当在 EdgeOne 内开启了图片处理参数,请求中携带的图片处理参数将默认参与 Cache Key 计算。

查询字符串

查询字符串是指请求 URL 中 ? 之后的字符串参数(包含一个或多个参数,用 &分隔),例如:https://www.example.com/images/example.jpg?color=blue&size=large 中的 color=blue&size=large

EdgeOne 支持自定义保留指定查询字符串的内容来区分缓存。
注意:
当保留查询字符串作为缓存键时,如果参数的位置顺序发生变化,缓存键也会变化。
例如:当客户端分别发起以下请求:
请求 A:https://www.example.com/Image/test.jpg?version=1&type=a
请求 B:https://www.example.com/Image/test.jpg?version=2&type=a
请求 C:https://www.example.com/Image/test.jpg?type=a&version=1
配置
缓存行为
查询字符串配置为全部保留
请求 A 和请求 B 所携带参数内容不同,对应不同的缓存版本,请求 A 和请求 C 参数内容一致,但是顺序不同,也对应不同的缓存版本。
查询字符串配置为全部忽略
请求 A、B、C 均对应同一份缓存版本。
查询字符串配置为保留指定参数 Type
请求 A、B 的参数顺序及内容完全一致,对应同一份缓存版本;请求 B 和请求 C 的 参数内容相同,但是顺序不同,对应不同的缓存版本。
查询字符串配置为忽略指定参数 Type
请求 A 和请求 B 剩余参数的内容不一致,对应不同的缓存版本;请求 A 和请求 C 剩余参数的内容一致,但是顺序不一致,对应不同的缓存版本。

HTTP 请求头

EdgeOne 支持将指定的 HTTP 请求头加入缓存键 Cache Key 的计算中,EdgeOne 边缘节点将根据请求头内容来建立不同的缓存版本。请求头的顺序变化,不影响 Cache Key的计算。
例如:指定HTTP请求头 User-Agent 加入缓存键计算中,以下请求 A 与请求 B 的 URL 及参数内容一致,但是 User-Agent 头内容不一致,将对应不同的缓存版本。
请求 A:https://www.example.com/Image/test.jpg?version=1&type=a,携带 User-Agent:chrome
请求 B:https://www.example.com/Image/test.jpg?version=1&type=a,携带 User-Agent:ios

Cookie

EdgeOne 支持将指定的 Cookie 内参数加入到缓存键的计算中,根据 Cookie 参数及内容区分缓存版本。Cookie 内多个参数参与 Cache Key 计算时,参数的顺序变化不影响 Cache Key 的计算。
例如:指定 Cookie 内参数 User 加入缓存键计算中,以下请求 A 和请求 B 参数内容相同,对应同一份缓存,请求 A 与请求 C 参数内容不同,对应不同版本的缓存。
请求 A:https://www.example.com/Image/test.jpg?version=1&type=a,携带 Cookie:User=A;ID=1
请求 B:https://www.example.com/Image/test.jpg?version=1&type=a,携带 Cookie:User=A;ID=2
请求 C:https://www.example.com/Image/test.jpg?version=1&type=a,携带 Cookie:User=B;ID=1

了解更多