重新整理和預熱相關常見問題

• 重新整理和預熱有什麼區別？

• 重新整理和預熱有先後順序嗎？

• 重新整理預熱時，輸入來源站點URL還是加速網域名稱URL？

• 如何重新整理泛網域名稱的緩衝？

• 重新整理和預熱任務需要多久生效？

• 預熱時能攜帶自訂要求標頭預熱嗎？

• 如何提高重新整理和預熱的每日配額上限？

• 是否支援自動化重新整理或預熱？

• 如何查看CDN的預熱任務是否執行完成？

• 配置CDN後如何對檔案進行同名更新？

• 預熱失敗了怎麼辦？

• 為什麼使用CDN重新整理預熱功能後訪問的資源沒有更新？

• 是否需要分別對HTTP和HTTPS重新整理和預熱？

• 是否支援預熱M3U8檔案？

• 已經進行了緩衝預熱，為什麼下載速度先快後慢？

重新整理和預熱有什麼區別？

• 重新整理：把CDN所有節點上對應的緩衝資源標記為失效，當使用者再次請求時，CDN會直接回來源站點擷取對應的資源並返回給使用者，同時將資源重新緩衝到CDN節點。重新整理功能會降低快取命中率。

• 預熱：來源站點主動將對應的資源緩衝到CDN節點，當您首次請求資源時，即可直接從CDN節點擷取到最新的資源，無需再回來源站點擷取。預熱功能會提高快取命中率。

重新整理和預熱有先後順序嗎？

重新整理和預熱通常是兩種不同的操作，並不一定有嚴格的先後順序。但在實際應用中，根據情境可能會有一個自然的邏輯順序。當您的來源站點資源更新，需要更新CDN節點緩衝時：

1. 先重新整理：刪除CDN緩衝中的舊檔案，讓後續的訪問都能擷取到來源站點上最新的內容。

2. 後預熱：待重新整理任務生效後再進行預熱操作，將最新的內容緩衝到CDN節點，保證使用者第一時間擷取到速度最快的服務。

3. 如果您首次接入CDN，節點無緩衝，可以直接執行預熱操作，將資源緩衝到CDN節點。

重新整理預熱時，輸入來源站點URL還是加速網域名稱URL？

重新整理預熱是對加速網域名稱對應的URL內容進行操作，所以，您需要輸入的是基於加速網域名稱下的URL，而不是來源站點的原始URL。這樣做的原因是CDN系統通過加速網域名稱來識別和管理緩衝資源，對加速網域名稱下指定路徑的請求進行重新整理或預熱，可以確保CDN節點上的緩衝內容得到及時更新或提前載入。

如何重新整理泛網域名稱的緩衝？

阿里雲CDN不支援直接重新整理整個泛網域名稱下的所有緩衝內容，需要對具體的子網域名稱對應的目錄或特定URL路徑分別提交重新整理請求，不能直接輸入https://*.example.com/file01.html或https://*.example.com/file02/。重新整理多個URL時，請按照一行一個URL進行輸入。

重新整理和預熱任務需要多久生效？

• 重新整理任務從提交到生效，大約需要5~6分鐘，如果檔案或者目錄配置的緩衝到期時間少於5分鐘，您無需執行重新整理操作，等待檔案或者目錄緩衝逾時更新即可。

• 預熱任務從提交到預熱完成，實際執行時間視預熱檔案大小而定，大約需要5~30分鐘，檔案平均大小越小，預熱速度越快。

預熱時能攜帶自訂要求標頭預熱嗎？

預熱請求預設攜帶的header是Accept-Encoding:gzip，如果您需要預熱請求攜帶其他header，或者實現多副本預熱，那麼可以使用OpenAPI介面PushObjectCache-預熱URL，並通過設定請求參數WithHeader來實現自訂預熱header。

如何提高重新整理和預熱的每日配額上限？

• URL重新整理和目錄重新整理

  預設情況下，一個帳號每日最多可以提交10,000條URL重新整理和100條目錄重新整理，目錄重新整理包含子目錄。如果您的阿里雲帳號的日頻寬峰值大於200Mbps，您可以通過配額管理申請提升每日配額，阿里雲將根據您業務的實際需求進行評估和配置。

• 正則重新整理

  預設情況下，一個帳號每日最多可以提交20條正則重新整理，如果您的阿里雲帳號的日頻寬峰值大於10Gbps，您可以通過提交工單來申請提升每日配額。

• 預熱

  預設情況下，一個帳號每日最多可以提交1000條URL預熱任務，如果您帳號的日頻寬峰值大於200Mbps，可通過配額管理申請提升每日配額，阿里雲將根據您業務的實際需求進行評估和配置。

  每個帳號的預熱隊列最大為100,000條URL，CDN根據URL提交的先後順序進行預熱；當預熱隊列中待預熱的URL達到了100,000條時，CDN將會拒絕接收新的預熱任務。

是否支援自動化重新整理或預熱？

如果您需要自動化重新整理或預熱，請參見使用自動化指令碼重新整理和預熱。

如何查看CDN的預熱任務是否執行完成？

1. 登入CDN控制台。

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

3. 操作类型選擇预热，在URL框內輸入URL地址，單擊提交。提交預熱任務後，您可以在操作记录頁簽中查看資源預熱的詳細記錄和進度。預熱進度為100%，表示預熱任務執行完成。預熱數量多會影響預熱進度，請您耐心等待。

   說明

   預熱任務的狀態為成功，表示預熱任務提交成功，並不代表檔案已經預熱結束。

4. 執行如下命令，查看預熱任務的執行狀態。

   curl -I 'http://example.aliyundoc.com/test.json'

   系統顯示類似如下。

   說明

   • Via的前半部分代表L2節點狀態，其中的“H”表示命中，說明檔案已經預熱到L2節點，不需要再回來源站點。

   • Via的後半部分代表L1節點的狀態，“M”表示L1節點上沒有緩衝，需要向L2節點回源。

相關文檔

調用DescribeRefreshTaskById，查詢重新整理狀態和預熱狀態是否在全網生效，詳情請參見DescribeRefreshTaskById - 查詢重新整理預熱任務-按ID。

配置CDN後如何對檔案進行同名更新？

使用CDN加速資源時，請參見以下方法進行檔案更新：

• 建議您來源站點的內容不使用同名更新，而是採用版本號碼的方式同步。

  為了能準確找到更新前和更新後的來源站點內容，建議您來源站點的內容以版本號碼的方式同步，即更新來源站點內容時採用不同的名稱。例如，採用img-v1.0.jpg、img-v2.1.jpg的方式命名。

• 對於必須進行同名更新的檔案，可以從控制台或是OpenAPI提交重新整理請求。控制台操作請參見重新整理和預熱資源，OpenAPI操作請參見重新整理預熱。使用CDN重新整理預熱功能後，訪問的資源如沒有更新，請參見為什麼使用CDN重新整理預熱功能後訪問的資源沒有更新？

預熱失敗了怎麼辦？

預熱失敗的可能原因是：

1. 確認URL正確性：驗證預熱的URL是否正確，包括是否有拼字錯誤、路徑錯誤或者檔案實際不存在等問題，確認URL是否可以直接在瀏覽器中訪問。

2. 檢查來源站點狀態：確認來源站點伺服器是否正常工作，沒有出現過載或宕機情況，如不能正常訪問也將造成預熱失敗。

3. 控制預熱任務的數量：如果同時提交了大量的預熱任務，可能會因為系統繁忙導致一部分任務失敗。預熱時請盡量分批次執行，避免對來源站點頻寬造成過大壓力。

4. 檢查資源可緩衝性：

   • 確認預熱的資源是否允許被緩衝。如果資源設定了Cache-Control頭部為no-cache、no-store或private，並且CDN配置遵循來源站點頭資訊，則會導致資源無法被緩衝。

   • 檢查資源對應的緩衝到期時間（如Expires或max-age），確保其不是0，非零值表示資源可以被緩衝。

   CDN緩衝規則請參見阿里雲CDNDCDN預設緩衝規則及優先順序。

5. 目前不支援預熱目錄。

為什麼使用CDN重新整理預熱功能後訪問的資源沒有更新？

問題原因

導致資源沒有更新的常見原因有以下3種：

• 使用CDN重新整理預熱雖然清除了CDN緩衝，但是受到瀏覽器緩衝的影響，導致訪問到舊的資源。

• 來源站點的資源沒有更新，本身就是舊的資源。

• 重新整理預熱任務沒有執行完畢。

解決方案

根據問題原因選擇其對應的解決方案：

• 嘗試清理瀏覽器緩衝，然後重新整理頁面，查看資源是否更新。

• 將網站網域名稱直接繫結來源站（通過修改本地host的方式），直接存取來源站點，檢查來源站點的資源是否更新。如果資源沒有更新，請更新來源站點的資源，再使用CDN加速。

• 登入CDN控制台，檢查重新整理預熱任務是否執行完畢，如果沒有執行完畢，建議重新執行任務，如何執行請參見重新整理和預熱資源。

是否需要分別對HTTP和HTTPS重新整理和預熱？

不需要，只需要重新整理或預熱HTTP或HTTPS其中一種即可。例如您需要預熱aaa.mp4檔案，您只需預熱https://example.com/aaa.mp4即可，不必再預熱http://example.com/aaa.mp4。

是否支援預熱M3U8檔案？

M3U8檔案是一種基於HTTP Live Streaming (HLS) 的視頻流媒體播放清單格式，它由蘋果公司開發。M3U8是M3U播放清單檔案的擴充，其中“8”代表檔案使用UTF-8字元編碼。該檔案格式通常用於線上流媒體服務，以提供連續播放的多媒體內容。M3U8檔案是一個純文字檔案，包含了分段（通常是TS或MP4檔案）視頻檔案的路徑資訊，這些分段視頻檔案被稱為“切片”。

預熱只作用於M3U8檔案本身，不會自動預熱列表中引用的各個TS切片檔案。您可以使用指令碼來預熱M3U8檔案，詳情請參見CDN和ApsaraVideo for VOD中使用指令碼重新整理預熱M3U8資源。

已經進行了緩衝預熱，為什麼下載速度先快後慢？

CDN預熱是多個節點同時進行下載，開始某個節點的下載速度較快，隨著更多節點的加入，下載速度受到來源站點伺服器頻寬的影響，呈現先快後慢的情況。對於頻寬較小的來源站點伺服器所需預熱時間會長一點，因此，可以通過升級頻寬來解決或者使用OSS來儲存大檔案。使用CDN對OSS資源進行加速，以獲得更好的加速效果。