覆盤平常問題板的時候,看到了曾經聽到後端同窗討論的回源的問題。一直以來對 cdn 相關的知識只知其一;不知其二,藉此機會完全梳理一下。html
通常的過程咱們都知道了,再也不贅述。下面咱們來看看訪問 cdn 的過程。 git
簡單來講,其實 cdn 就是個放服務端資源的一個倉庫。康師傅的泡麪若是不是有家門口的小賣部,咱們就得去人家的工廠門口拿。有了小賣部,咱們只須要去一個賣康師傅&&有貨的小賣部拿,就是這個道理。github
其中有一個比較重要的點,在過程1裏:這個過程當中,有一個 CNAME 的過程,咱們訪問 cdn 資源的地址通常是 a.cloud.com 或者相似的地址,是一個公司的訪問 cdn 的專用地址。可是咱們用的 cdn 的服務倒是第三方的,即其實資源在他們的地址上好比 tencent.cdn。這時候就須要在 dns 查詢的時候,須要把咱們訪問 a.cloud.com的地址映射到 tencent.cdn 的地址上,而後拿着映射後的地址再去走一遍 dns 解析,成功以後才獲取到第三方提供的全局負載均衡系統的 IP。再繼續走後面的流程。web
當 cdn 緩存服務器中沒有符合客戶端要求的資源的時候,緩存服務器會請求上一級緩存服務器,以此類推,直到獲取到。最後若是仍是沒有,就會回到咱們本身的服務器去獲取資源。 那都有哪些時候會回源呢?沒有資源,資源過時,訪問的資源是不緩存資源等都會致使回源。其餘狀況歡迎小夥伴們在評論區補充~數據庫
注意題目所描述的狀況不是 cdn 的動態加速。後端
動態加速的對象是動態生成的網頁,動態加速通常是對針對內容(如數據庫信息等)在用戶與- 源站之間創建高速通道,經過路由優化、TCP加速等技術手段對動態內容進行加速,下降節點到源站之間的時延,從而大大下降了用戶訪問動態網頁的延遲。api
其實這個問題我沒有找到比較合適的解答,下面我想說一下我我的的看法。 咱們使用 cdn 的緣由是,咱們常常有一些比較頻繁請求且容量比較大的文件,而且更新頻率不那麼高的文件。這些文件若是咱們都放在本身的服務器上,於客戶端問題在於訪問時間長,於服務器端是佔用服務器端的資源。因此咱們採用分佈式的方式扔在 cdn 上。可是 API 不一樣,首先他常更新,其次他多和用戶信息等相關聯,而且 cdn 判斷是否緩存是依靠 url,意味着他只能緩存 get 請求,因此他的應用範圍是有限的。而且 api 常更新,推送更新到全部 cdn 節點一樣是須要耗費資源的。因此 API 是不適合放在 cdn 上的。可是若是你的內容是相對靜態的,不涉及和用戶信息關聯,而且能在一段時間內容忍緩存,更新不頻繁,那麼也不是不能考慮。緩存
資源過時時間就是根據咱們老生常談的請求頭部來斷定。這個後面會單拎出一篇文章帶你們複習一下。 那麼 cdn 是如何更新數據的?分兩種,主動(PUSH)和被動(PULL)。被動剛纔咱們已經提到過了,利用回源就能夠被動在途經的 cdn 節點緩存數據。 而主動指的是,咱們從服務器主動往 cdn 推送數據。服務器
邊緣節點:指距離最終用戶接入具備較少的中間環節的網絡節點網絡
參考文獻: CDN 學習中的一點小思考 CDN 命中率、回源率常見問題 CDN緩存那些事 讓 API 也上 CDN 吧 CDN的基本工做過程 CDN是什麼?使用CDN有什麼優點? cname記錄是什麼?他存在的意義是什麼? CDN工做原理(CNAME) 【CDN 最佳實踐】CDN緩存策略解讀和配置策略 CDN緩存那些事兒