【 CDN 最佳實踐】CDN 命中率優化思路

摘要： CDN 在靜態資源的加速場景中是將靜態資源緩存在距離客戶端較近的CDN 節點上，而後客戶端訪問該資源便可經過較短的鏈路直接從緩存中獲取資源，而避免再經過較長的鏈路回源獲取靜態資源。所以 CDN的緩存命中率的高低直接影響客戶體驗，而保證較高的命中率也成爲了站長的核心命題。

點此查看原文：https://yq.aliyun.com/articles/288084?spm=a2c41.11181499.0.0

CDN 在靜態資源的加速場景中是將靜態資源緩存在距離客戶端較近的CDN 節點上，而後客戶端訪問該資源便可經過較短的鏈路直接從緩存中獲取資源，而避免再經過較長的鏈路回源獲取靜態資源。所以 CDN的緩存命中率的高低直接影響客戶體驗，而保證較高的命中率也成爲了站長的核心命題。在本文中咱們就一塊兒探討 CDN 緩存命中率的概念、影響因素以及優化策略。

一、緩存命中率的概念

CDN 的緩存命中率包括兩種：字節緩存命中率和請求緩存命中率。其中字節緩存命中率是指 CDN 緩存命中 Response 的字節數除以 CDN全部請求 Response 的字節數。而請求緩存命中率是指 CDN 緩存命中的請求的個數除以 CDN 全部的請求數。
從上面的描述中能夠查看到字節緩存命中率能夠表徵回源流量的大小，回源流量越高那麼源站的流出流量也就越大，這樣對於源站的帶寬資源以及其餘的負載都會越大，所以回源流量表明瞭源站服務器接收到的負載壓力。而咱們在業務使用中也主要關心字節緩存命中率。
查看緩存命中率主要包括控制檯、 CDN 日誌和 API/SDK 查看兩種方式。如今 CDN 控制檯上提供的命中率監控均是字節緩存命中率，如圖1 中所示便是控制檯監控信息中命中率的詳情。
                                    
                                                                        圖 1. 控制檯命中率監控示意圖


在CDN的請求日誌中，CDN記錄了全部的CDN請求的緩存命中狀態，詳細的日誌格式請參考CDN日誌格式，其中「cache命中狀態」字段爲HIT即表示命中，而MISS即表示未命中的狀態。這裏特別須要注意的一點是這裏的命中狀態僅表徵CDN的L1節點的命中狀態，當CDN的L1節點未命中緩存可是L2節點命中緩存的狀況下這裏仍然會顯示MISS。
而API/SDK的方式CDN分別提供了DescribeDomainHitRateData和DescribeDomainReqHitRateData兩個接口分別查詢的CDN的字節緩存命中率和請求緩存命中率。該接口是能夠查看到歷史90天內的全部的數據。
 

二、影響因素及優化建議

CDN的緩存規則同時按照CDN上的緩存規則、源站配置的Cache-Control等response頭、文件類型等綜合考慮，具體的緩存規則解讀建議查閱【 CDN 最佳實踐】CDN 緩存策略解讀和配置策略。那麼按照上述的緩存規則會影響命中率的因素主要有如下：


1. 文件類型是否適合於在CDN上緩存。
CDN在業務架構中負責加速靜態資源，所以若是動態資源也通過CDN的話是會致使CDN的命中率降低的。CDN判斷動態文件和靜態文件的標準是該文件的response頭中是否帶有Etag頭和Last-modified頭。這兩個頭在HTTP協議中分別經過文件內容和文件最後修改時間表徵文件的修改狀況。
所以建議用戶使用過程當中優化點：
網站架構是否適合於動靜分離。動靜分離是常見的網站優化的策略，主要是經過將靜態資源和動態資源分離成兩個站點提供服務。靜態資源因爲長時間不會發生變化，所以可使用CDN加速；而動態資源由於須要實時獲取源站的資源而且可能源站加載須要一段時間（CDN回源獲取數據有嚴格的的回源超時時間，動態文件響應較慢可能致使CDN回源直接拋出504錯誤）而直接解析到源站服務器拉取資源。
靜態文件文件是否在response頭中返回Etag頭和Last-modified頭。在CDN上沒有配置緩存規則的狀況下，靜態文件沒有返回Etag頭和Last-modified頭也一樣會致使該靜態資源不在CDN節點上緩存。如圖2中所示，x-swift-cachetime頭即表示該文件在CDN上的緩存時間（單位是秒）。該文件其實爲靜態文件，可是因爲response頭中沒有Etag和Last-modified致使CDN並不會該文件進行緩存。
                                    
                                                                        圖 2. CDN 緩存時間示意圖
配置合理的源站緩存規則。源站服務器能夠針對於資源配置其緩存規則。當源站配置瞭如下response頭時CDN將不會對該文件進行緩存：
    1）有s-maxage=0，no-cache，no-store，private其中一種
    2）若是沒有s-maxage或者s-maxage=0，而且有max-age=0.
    3）帶Pragma: no-cache
並且上述的response頭在CDN緩存規則中將有最高優先級（即便CDN上配置了緩存規則也不緩存），所以上述的這些response頭並不適合於配置於源站的靜態資源的。另外當CDN上沒有配置緩存規則時,資源的緩存規則將按照源站的Cache-Control或者Expires頭進行緩存（Cache-Control優先級比Expires高），所以建議用戶設置合理的Cache-Control或者Expires頭。
配置緩存規則。上面所指的沒有包括Etag和Last-modified頭而致使CDN緩存時間爲0的場景是CDN控制檯上沒有配置緩存配置時會出現這種狀況，所以若是用戶的靜態資源確實沒法配置上述兩個response頭的話是能夠考慮針對該文件配置緩存規則，這樣該文件便可在CDN上按照緩存規則進行緩存。


2. CDN的刷新和預熱功能
CDN提供了刷新緩存和預熱緩存兩個操做。兩個操做都會對緩存命中率有影響，可是兩個操做的影響是徹底相反的。所以用戶是須要了解兩個操做的概念以及使用場景。
刷新功能是指將特定URL或者目錄下的全部歷史緩存的內容清除掉，該操做經常使用於源站進行同名更新後致使CDN緩存內容已爲歷史髒數據，刷新後將使URL下次訪問時直接回源。所以會致使命中率降低。
預熱功能是將URL提早上傳到CDN的L2節點上，這樣下次訪問的時候就不須要從源站再拉取資源了，所以預熱是沒有直接致使L1的命中率升高，但提高了CDN的真實命中率。
所以建議用戶使用過程當中優化點：
慎重使用刷新功能。刷新功能確定是會致使命中率出現降低的，特別是對於加速域名根目錄的刷新任務會致使加速域名下的全部緩存均無效，勢必會致使後續出現大量回源請求致使源站服務器負載升高。所以請用戶在實際線上環境特別是高峯期進行刷新操做。另外建議客戶儘可能避免執行靜態資源同名更新，能夠嘗試經過添加queryString的方式進行版本更替（例如url中帶有?version=1.1等方式）。
業務高峯前預熱熱門資源。預熱能夠提早將資源預熱到CDN的L2節點，避免業務高峯對於源站產生壓力，也同時保證了CDN的真實命中率。可是預熱的請求次數天天客戶均是有條數限制的，所以建議客戶能夠根據歷史的熱門資源統計得要待預熱的資源URL進行操做。


3. CDN緩存規則是否合理
CDN上是能夠針對於目錄或者後綴名設置緩存配置的。而在CDN和源站同時配置緩存規則時是會以CDN上的緩存規則優先的（除非源站設置了不容許緩存的規則），所以建議用戶在CDN控制檯中設置合理的緩存規則，避免走默認的緩存規則致使頻繁回源（默認緩存常常緩存3600秒過時）。另外特別注意CDN控制檯上配置的緩存時間爲0秒時該資源並非客戶端直接請求到源站的，而是客戶端請求仍然會先到CDN節點，而後由CDN節點觸發回源請求到源站獲取資源，而且流出流量仍然會計算CDN的流出流量。


4. 可變參數致使命中率降低
客戶請求的URL中常帶有queryString，例如上面所說的請求URL中爲了區分版本帶上?version=1.1等參數或者CDN回源到私有讀寫類型的bucket時會帶上OSS私有訪問須要的OSSAccessKeyId、Expires和Signature參數。在CDN處理的過程當中默認的處理邏輯是對於一樣的URL而帶有不一樣queryString的請求會認爲徹底不一樣的請求，所以緩存也對應的是不一樣份，這就會致使若是queryString參數發生變化時會致使從新回源，所以命中率會出現降低的狀況。
所以建議用戶使用過程當中優化點：
業務系統容許的狀況下使用「過濾參數」功能。開啓過濾參數功能後，CDN接收到queryString的URL替換成沒有帶參數的URL。例如請求URL爲http://www.aliyun.com/1.jpg?version=1，開啓過濾參數後將替換URL爲http://www.aliyun.com/1.jpg，這樣講查看是否存在有http://www.aliyun.com/1.jpg的緩存，若是有的話將直接返回客戶端；若是沒有緩存的話就會按照http://www.aliyun.com/1.jpg請求回源站。所以業務系統容許queryString不敏感的狀況下能夠開啓該功能。可是對於一些系統須要queryString進行傳參或者設置跳轉邏輯的話就不能開啓該功能。
對於CDN加速OSS的場景建議使用「私有bucket回源」功能。當OSS設置爲私有時不能夠開啓過濾參數而且當簽名querystring發生變化時還會影響CDN緩存命中率。而「私有bucket回源」功能將使CDN的請求回源OSS的時候自動帶上簽名querystring參數，而不須要客戶本身在請求CDN的時候設置。這樣即實現了OSS自己資源的安全防禦而又不影響CDN的緩存命中率。


5. CDN加速域名流量較低
CDN節點做爲全部使用CDN的用戶公用的節點資源，所以CDN配置的緩存規則表示了該資源在CDN上的緩存最長時間，若是用戶在CDN上的緩存資源的熱度較低的話是有可能被提早踢出CDN節點的緩存的。所以能夠理解爲緩存按照熱度屬性採起末尾淘汰制，所謂熱度就是該文件在該節點上被訪問的頻率，文件熱度不夠即被提早剔除。
所以建議用戶使用過程當中優化點：
對於流量較低的域名能夠提早按期將熱度資源預熱到CDN節點上，避免影響業務使用。
建議用戶考慮對於流量較低的域名能夠不使用CDN加速，這樣的域名的加速效果並不明顯。