CDN：重新整理和預熱資源

資源重新整理

重新整理操作的本質是向邊緣節點下發緩衝失效指令，而非直接刪除檔案。邊緣節點收到指令後，會將匹配的緩衝資源標記為"失效"或"到期"。當使用者再次請求該資源時，邊緣節點發現緩衝已失效，便會回源擷取最新資源，並在返回給使用者的同時重新緩衝。

控制台預設重新整理方式說明：在CDN控制台執行目錄重新整理或正則重新整理時，預設採用標記重新整理方式。標記重新整理僅標記緩衝到期，當邊緣節點回源時，會攜帶If-Modified-Since或If-None-Match要求標頭。若來源站點返回304 Not Modified，邊緣節點將保留舊快取複本。這種方式可節省回源流量，但在某些情境下（如來源站點同名更新、違規內容清理、配置變更後）可能導致使用者仍訪問到舊內容。若需徹底清除緩衝，建議使用API調用重新整理緩衝介面，並將Force參數設定為true進行強制重新整理。

適用情境

• 資源更新和發布：來源站點的舊資源更新或升級後，為避免使用者仍訪問到舊的緩衝資源，可提交對應資源的URL或目錄進行重新整理，確保使用者訪問到最新的資源並緩衝至邊緣節點。

• 違規資源清理：來源站點存在不合規內容時，刪除來源站點資源後，由於邊緣節點仍可能存在緩衝，資源仍可能被訪問到。此時可通過URL重新整理功能更新緩衝資源，確保違規內容及時清除。

資源預熱

預熱操作由邊緣節點根據提交的URL列表，主動向來源站點發起請求，將資源緩衝到邊緣節點上，而非來源站點主動推送。預熱可提升新資源或活動頁面的首次訪問速度，同時減少活動上線時的回源壓力，保護來源站點。

預熱機制說明：預熱操作預設將資源緩衝至L2回源節點（二級緩衝層），而非直接分發至所有L1邊緣節點。當使用者首次訪問某資源時，L1邊緣節點會從L2回源節點或來源站點拉取內容並緩衝。因此，預熱操作主要解決的是降低來源站點壓力的問題，L1邊緣節點的全面緩衝覆蓋依賴於使用者的實際訪問分布。只有當使用者實際訪問某L1節點後，該節點完成本機快取，後續同地區使用者才能直接從L1命中緩衝獲得加速。

適用情境

• 首次接入CDN：首次接入CDN後，可將熱點靜態資源提前預熱至邊緣節點。使用者訪問時可直接由邊緣節點響應，避免初次訪問速度慢的問題，提升使用者體驗。

• 營運活動：營運大型活動時，提前將活動頁涉及的靜態資源預熱至邊緣節點。活動開始後，使用者訪問的所有靜態資源均已緩衝至邊緣節點，由邊緣節點直接響應，確保活動頁面快速載入。

• 安裝包或其他大檔案發布：新版本安裝包或升級包發布前，提前將資源預熱至邊緣節點。產品正式上線後，使用者的下載請求將直接由邊緣節點響應，提升下載速度，降低來源站點壓力。

緩衝層級與效果

預熱操作主要將資源緩衝至 L2 匯聚節點，而非所有 L1 邊緣節點。使用者首次訪問時，L1 邊緣節點會從 L2 節點或來源站點拉取資源。因此，預熱的主要目的是降低來源站點壓力，而非保證所有 L1 邊緣節點立即命中緩衝。

• 效果評估：預熱有助於提升快取命中率，但對於小檔案或非熱點檔案，建議合理評估預熱成本。預熱會產生回源流量，大致等於單個檔案大小乘以 L2 節點數量。

重新整理資源

1. 登入CDN控制台。

2. 在左側導覽列，單擊刷新预热。

3. 在重新整理緩存/預熱緩衝頁簽，選擇操作類型為刷新。

4. 根據需求選擇重新整理方式並提交任務。

如何?全站重新整理（全域/根目錄重新整理）

CDN 不支援一鍵全站重新整理，但您可以通過以下方式實現全站重新整理：

1. 目錄重新整理：在操作方式中選擇目录，輸入欄位名根目錄 URL（如 https://www.example.com/）。URL 必須以 / 結尾。

2. 強制重新整理（API）：若目錄重新整理後部分節點仍返回舊緩衝，建議調用重新整理緩衝 API（RefreshObjectCaches），將 Force 參數設定為 true 進行強制重新整理。強制重新整理將無條件刪除節點上的緩衝資源，確保下次訪問回源擷取最新內容。

   說明

   控制台的重新整理表單不支援設定 Force 參數，如需使用強制重新整理，請通過 API 或 SDK 調用。

3. 單擊提交，系統開始執行重新整理任務。

   • 重新整理任務一旦提交成功，無法中止。

   • 重新整理任務通常需要 5~6 分鐘在全網生效。如果緩衝到期時間小於此值，則無需手動重新整理。

   • 如果在OSS控制台開啟了CDN緩衝自動重新整理，則無法通過 CDN 控制台查看 OSS 的緩衝自動重新整理任務。

預熱資源

1. 登入CDN控制台。

2. 在左側導覽列，單擊刷新预热。

3. 在重新整理緩存/預熱緩衝頁簽，選擇操作類型為预热。

4. 在 URL 輸入框中輸入需要預熱的完整檔案 URL，每行一個。不支援預熱目錄。例如：https://www.example.com/install/package.zip。

5. 單擊提交，系統開始執行預熱任務。

   • 預熱任務一旦提交成功，無法中止。

   • 預熱任務的完成時間取決於檔案大小、數量和來源站點效能，通常需要 5~30 分鐘。

預熱 OSS 檔案注意事項

當來源站點為 OSS 時，預熱 URL 須注意以下規範：

• URL 格式：必須填寫 CDN 加速網域名稱的完整 URL（如 https://cdn.example.com/path/file.zip），不能填寫來源站點 OSS 的內網或外網地址（如 https://examplebucket.oss-cn-hangzhou.aliyuncs.com/...）。

• 簽名參數：預熱 URL 中不得包含 OSS 的臨時簽名參數（如 Expires、OSSAccessKeyId、Signature 等）。這些是臨時授權參數，會導致預熱失敗。請使用不含簽名的永久可存取 URL。

• 來源站點響應狀態代碼：預熱要求來源站點返回 200 狀態代碼。若來源站點返回 308 重新導向或其他非 200 狀態代碼，預熱任務將失敗。例如，URL 末尾缺少斜杠導致 OSS 返回重新導向時，應補全斜杠後重新提交。

自動化重新整理或預熱

存在以下情況時，建議使用自動化指令碼重新整理和預熱：

• 無開發人員，需手動提交重新整理預熱任務，營運成本高。

• 重新整理或預熱URL過多，分批提交導致效率低。

• 需要人工或程式判斷重新整理預熱任務是否正常進行。

標記重新整理（CDN預設策略）

• 適用情境：常規內容更新，如發布新版靜態檔案。

• 機制：這是目錄重新整理和正則重新整理在控制台上的預設行為。CDN 邊緣節點在回源時，會攜帶If-Modified-Since或If-None-Match要求標頭。來源站點會根據這些頭資訊判斷資源是否已更新。

• 效果：如果來源站點資源未變更，來源站點將返回304 Not Modified狀態代碼，CDN 邊緣節點會繼續使用舊的快取複本，不會消耗回源流量。這是一種節省成本和來源站點資源的最佳化方式。若需徹底清除緩衝（如違規清理、配置變更、同名檔案更新），標記重新整理可能無法滿足需求，請使用強制重新整理。

強制重新整理

• 適用情境：緊急清理違規或錯誤資源、修複錯誤的Cache-Control回應標頭配置後需要強制全網更新、來源站點檔案同名更新等情境。

• 機制：通過重新整理緩衝提交重新整理任務時，將參數Force設定為true來觸發。此模式下，CDN 邊緣節點會無條件地將緩衝資源標記為失效，不再進行304校正。

• 效果：下次訪問該資源時，CDN 邊緣節點將必須回源擷取新版本，即使來源站點上的檔案並未改變。

強制重新整理的典型應用情境

以下情境建議使用強制重新整理（通過重新整理緩衝 API設定 Force=true）：

• 違規內容或木馬清理：來源站點刪除惡意檔案後，必須使用強制重新整理，或確保來源站點對該 URL 返回正確的 HTTP 狀態代碼（如 404）。否則邊緣節點可能因標記重新整理回源校正後仍保留舊緩衝，繼續提供違規內容。

• 同名檔案更新（配置變更）：若來源站點檔案同名替換但內容不同，標記重新整理可能因來源站點返回 304 Not Modified 狀態代碼而繼續使用舊緩衝。此時應使用強制重新整理確保全網更新到最新內容。

• 頁面顯示異常或首頁迴圈：若訪問網站其他頁面時一直顯示首頁，或圖片顯示異常，且 URL 重新整理無效，建議使用目錄重新整理並通過 API 設定 Force=true 進行強制重新整理。

API 強制重新整理參數樣本：

{
  "ObjectType": "Directory",
  "ObjectPath": "https://www.example.com/static/",
  "Force": true
}

關鍵參數說明：

• ObjectType：填寫Directory（目錄）或File（檔案）。

• ObjectPath：填寫以/結尾的完整目錄路徑，或具體的檔案URL。

• Force：設定為true開啟強制重新整理，忽略來源站點的If-Modified-Since/If-None-Match校正，直接清除緩衝。