边缘加速
  • 站点加速
    • 概述
    • 快速导入导出站点配置
    • 访问控制
      • Token 鉴权
      • 认证方法A
      • 认证方法B
      • 认证方法C
      • 认证方法D
      • 认证方法V
    • 智能加速
    • 文件优化
      • 智能压缩
    • 网络优化
      • 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 回源请求头
    • 自定义错误页面
    • 请求与响应行为
      • HTTP响应
      • 请求处理顺序
      • EdgeOne 默认 HTTP 回源请求头
      • EdgeOne 默认 HTTP 响应头
      • HTTP限制
    • 媒体服务
      • 音视频预拉取
      • 实时图片处理
      • 实时媒体处理
      • 点播媒体源
  • 四层代理
    • 概述
    • 新建四层代理实例
    • 修改四层代理实例配置
    • 停用/删除四层代理实例
    • 批量配置转发规则
    • 获取客户端真实IP
      • 通过 TOA 获取 TCP 协议客户端真实 IP
      • 通过 Proxy Protocol V1/V2 协议获取客户端真实 IP
        • 概述
        • 方式一:通过 Nginx 获取客户端真实 IP
        • 方式二:在业务服务器解析客户端真实 IP
        • Proxy Protocol V1/V2 获取的客户端真实 IP 格式
      • 通过 SPP 协议传递客户端真实 IP
  • 边缘 DNS
    • 概述
    • 托管域名 DNS 解析
      • 修改 DNS 服务器
      • 配置域名 DNS 解析记录
      • 批量导入DNS记录
      • DNS 高级配置
      • 解析线路与对应代码枚举
    • 接入加速域名
      • 添加加速域名
      • 站点/域名归属权验证
      • 修改 CNAME 解析
      • 验证业务访问
    • 别称域名
      • 概述
      • 配置指南
      • 通过别称域名批量接入 SaaS 建站域名
      • 别称域名实现业务的容灾
    • 流量调度
      • 流量调度管理
    • 源站配置
      • 回源配置
        • 回源超时
        • 配置回源 HTTPS
        • Host Header 重写
        • 回源请求参数设置
        • 回源跟随重定向
        • HTTP/2 回源
        • 分片回源
      • 负载均衡
        • 概述
        • 快速创建负载均衡实例
        • 健康检查策略介绍
        • 查看源站健康状态
        • 相关参考
          • 负载均衡相关概念
          • 请求重试策略介绍
      • 源站组操作指引
      • 相关参考
        • 旧版源站组兼容相关问题
  • 边缘缓存
    • 概述
    • EdgeOne 缓存规则介绍
      • EdgeOne 内容缓存规则
      • 缓存键(Cache Key)介绍
      • Vary 特性
    • 缓存配置
      • 自定义 Cache Key
      • 节点缓存 TTL
      • 状态码缓存 TTL
      • 浏览器缓存 TTL
      • 离线缓存
      • 缓存预刷新
    • 清除和预热缓存
      • 清除缓存
      • 预热缓存
    • 如何提高 EdgeOne 的缓存命中率
  • 规则引擎
    • 概述
    • 规则引擎支持的匹配类型与操作
    • 规则管理
    • 变量
当前内容仅提供英语版本,中文版我们将尽快补充,感谢您的理解。

缓存预刷新

Feature Introduction

After the cache resources expire within the EdgeOne node, EdgeOne will follow the origin to obtain the latest resource files when receiving the corresponding client requests, which may cause a large increase in origin-pull requests during peak periods. The cache pre-refresh function can verify the validity of cache resources before they expire, without waiting for expiration, which helps maintain the real-time nature of resources and respond to requests more quickly. The cache pre-refresh time can be configured according to the percentage of the file cache TTL.

Usage Scenarios

Since the cache pre-refresh function can verify the validity of resources in advance, it is suggested to use it in scenarios where content needs to be frequently updated or user experience is highly demanded:
High Real-time Requirements: For content that needs to be updated quickly, such as news, event pages, etc., customers hope that users can obtain the latest resources when requesting. By enabling the cache pre-refresh function, the node verifies and updates the cache before the resources expire, ensuring that users can obtain relatively new resources when accessing, thus avoiding additional waiting time when users request and improving user experience.
Reduce Origin-pull Pressure: For some hotspot resources, a large number of origin-pull requests may be triggered after expiration. Enabling the cache pre-refresh function can advance these origin-pull requests, reducing the concentration of a large number of origin-pull requests when resources expire, thereby reducing origin-pull pressure.

Directions

Scenario One: Configure cache pre-refresh for all domain names of the site

If you need to configure the same cache pre-refresh for the whole connected site, or as a site-level fallback configuration, please refer to the following steps:
1. Log in to the EdgeOne console and click Site List in the left sidebar.In the site list, click the target Site.
2. On the site details page, click Site Acceleration to enter the Site Global Configuration page. In the right-hand navigation bar, click Cache Configuration.
3. Locate the Cache Pre-refresh card, click Switch, and enter the percentage value for the pre-refresh time in the pop-up confirmation box.

Configuration state: Default is enabled, can be turned off by clicking the slider.
Pre-refresh Time: The percentage of the node cache TTL, can enter an integer between 1-99. Default is 90%.

Scenario Two: Configure cache pre-refresh for specific domain names, paths, or file extensions, etc.

If you need to configure different cache pre-refresh for different domain names, paths, or file extensions, etc., for example: Configure a more advanced pre-refresh time - 60% for the www.example.com domain under the example.com site. Please refer to the following steps:
1. Log in to the EdgeOne console and click Site List in the left sidebar.In the site list, click the target Site.
2. On the site details page, click Site Acceleration to enter the global site configuration page, then click the Rule Engine tab.
3. On the rule engine management page, click Create rule and select Add blank rule.
4. On the rule editing page, select Host as the matching type and configure it as www.example.com.
5. Click on the Action, and in the pop-up operation list, select the operation as cache pre-refresh, and configure it as 60% of the TTL.
6. The complete configuration is shown below, click Save and Publish to complete the rule configuration.


Attachment: Functional Principle


Assuming that the specified image test.jpg has a node cache TTL of 10 seconds and a cache pre-refresh time of 80% of the TTL (i.e., 8 seconds), then:
1. When the node receives the client request for the first time, the current node does not cache the file, and it will follow the origin to pull the resource and cache it in the node, with a cache TTL of 10 seconds. Within 0-7 seconds, if the client request is received again, the node will directly provide the resource from the cache and normally respond to the client request;
2. When the test.jpg cached in the node reaches the pre-refresh time, between the 8th and 10th seconds, if the client request is received, the node will still normally respond to the client request, but at the same time, it will asynchronously follow the origin to verify whether the cache resource is valid;
If the resource is valid, the cache TTL of the resource on the node will be updated and reset to 10 seconds;
If the resource is invalid, the latest valid resource will be obtained from the origin to the node, and the node cache TTL will be reset to 10 seconds;
3. If no client requests are received after the file exceeds the node cache TTL, the cache will exceed the cache.
4. When the node receives a Client request next time, the node will send an origin-pull request to the origin to verify whether the resources are valid. If the file is updated, the latest file will be pulled, otherwise, the file will be cached again and the Cache time will be refreshed to 10 seconds.