4.4.2　內(nèi)容分發(fā)

在DNS服務(wù)器的協(xié)助下，無論是對用戶還是服務(wù)器，內(nèi)容分發(fā)網(wǎng)絡(luò)都可以是完全透明的，如在兩者都不知情的情況下，由CDN的緩存節(jié)點接管了用戶向服務(wù)器發(fā)出資源請求。后面隨之而來的問題是緩存節(jié)點中必須有用戶想要請求的資源副本，才可能代替源站來響應(yīng)用戶請求。這里面又包括兩個子問題：“如何獲取源站資源”和“如何管理（更新）資源”。CDN獲取源站資源的過程被稱為“內(nèi)容分發(fā)”，“內(nèi)容分發(fā)網(wǎng)絡(luò)”的名字正是由此而來，這也是CDN的核心價值。目前主要有以下兩種主流的內(nèi)容分發(fā)方式。

·主動分發(fā)（Push）：分發(fā)由源站主動發(fā)起，將內(nèi)容從源站或者其他資源庫推送到用戶邊緣的各個CDN緩存節(jié)點上。這個推送的操作沒有什么業(yè)界標(biāo)準(zhǔn)可循，可以選擇任何傳輸方式（HTTP、FTP、P2P，等等）、任何推送策略（滿足特定條件、定時、人工，等等）、任何推送時間，只要與后面說的更新策略相匹配即可。由于主動分發(fā)通常需要源站、CDN服務(wù)雙方提供程序API接口層面的配合，所以它對源站并不是透明的，只對用戶一側(cè)單向透明。主動分發(fā)一般用于網(wǎng)站要預(yù)載大量資源的場景。譬如在雙十一之前的一段時間內(nèi)，淘寶、京東等各個網(wǎng)絡(luò)商城會把未來活動中所要用到的資源推送到CDN緩存節(jié)點中，特別常用的資源甚至?xí)苯泳彺娴侥愕氖謾CApp的存儲空間或者瀏覽器的localStorage上。

·被動回源（Pull）：被動回源由用戶訪問所觸發(fā)，是全自動、雙向透明的資源緩存過程。當(dāng)某個資源首次被用戶請求的時候，若CDN緩存節(jié)點發(fā)現(xiàn)自己沒有該資源，就會實時從源站中獲取，這時資源的響應(yīng)時間可粗略認(rèn)為是資源從源站到CDN緩存節(jié)點的時間，加上資源從CDN發(fā)送到用戶的時間之和。因此，被動回源的首次訪問通常比較慢（但由于CDN的網(wǎng)絡(luò)條件一般遠(yuǎn)高于普通用戶，并不一定比用戶直接訪問源站更慢），不適合應(yīng)用于數(shù)據(jù)量較大的資源。被動回源的優(yōu)點是可以做到完全的雙向透明，不需要源站在程序上做任何配合，使用起來非常方便。這種分發(fā)方式是小型站點使用CDN服務(wù)的主流選擇，如果不是自建CDN，而是購買阿里云、騰訊云的CDN服務(wù)的站點，多數(shù)采用的就是這種方式。

對于“CDN如何管理（更新）資源”這個問題，同樣沒有統(tǒng)一的標(biāo)準(zhǔn)可言，盡管在HTTP協(xié)議中，關(guān)于緩存的Header定義中確實有對CDN這類共享緩存的一些指引性參數(shù)的定義，譬如Cache-Control的s-maxage，但是否要遵循，完全取決于CDN本身的實現(xiàn)策略。更令人感到無奈的是，由于大多數(shù)網(wǎng)站的開發(fā)和運維人員并不十分了解HTTP緩存機制，所以導(dǎo)致如果CDN完全照著HTTP Header來控制緩存失效和更新，效果反而會很差，還可能引發(fā)其他問題。因此，對CDN緩存的管理不存在通用的準(zhǔn)則。

現(xiàn)在，最常見的做法是超時被動失效與手工主動失效相結(jié)合。超時被動失效是指給予緩存資源一定的生存期，超過了生存期就在下次請求時重新被動回源一次。而手工主動失效是指CDN服務(wù)商一般會提供處理失效緩存的接口，在網(wǎng)站更新時，由持續(xù)集成的流水線自動調(diào)用該接口來實現(xiàn)緩存更新，譬如“icyfenix.cn”就是依靠Travis-CI的持續(xù)集成服務(wù)來觸發(fā)CDN失效和重新預(yù)熱的。