Cdn縮小的制作方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及內(nèi)容分發(fā)網(wǎng)絡(luò)，特定地，但不完全涉及內(nèi)容分發(fā)網(wǎng)絡(luò)中的邊緣緩存的受控關(guān)閉。
【背景技術(shù)】
[0002]內(nèi)容分發(fā)網(wǎng)絡(luò)(content delivery network 或者 content distribut1nnetwork，即⑶N)為通常部署在跨因特網(wǎng)的多個數(shù)據(jù)中心中的大型分布式系統(tǒng)。⑶N的目標(biāo)在于高可用性且高性能地提供內(nèi)容給終端用戶。CDN提供因特網(wǎng)內(nèi)容的一大部分，包括網(wǎng)頁對象(文本、圖形和腳本)、可下載對象(媒體文件、軟件、文檔)、應(yīng)用(電子商務(wù)、門戶)、直播流媒體、點播流媒體及社交網(wǎng)絡(luò)。

【發(fā)明內(nèi)容】

[0003]根據(jù)本發(fā)明實施方案，提供了在內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)中的系統(tǒng)組件，所述CDN包括請求路由器及多個邊緣緩存，所述請求路由器可操作為判定所述邊緣緩存中哪一個應(yīng)當(dāng)提供內(nèi)容給客戶端，所述系統(tǒng)組件包括處理器及用于存儲由處理器使用的數(shù)據(jù)的存儲器，其中所述處理器可操作為從客戶端接收內(nèi)容請求，并基于關(guān)閉第一邊緣緩存的決定(在客戶端已經(jīng)從第一邊緣緩存下載一些內(nèi)容之后)，參與在客戶端下載內(nèi)容當(dāng)中使客戶端從從第一邊緣緩存下載內(nèi)容轉(zhuǎn)移到從第二邊緣緩存下載內(nèi)容的處理，使得客戶端從第二邊緣緩存繼續(xù)下載內(nèi)容。
[0004]根據(jù)本發(fā)明實施方案，也提供了客戶端設(shè)備，所述客戶端設(shè)備包括處理器及用于存儲由處理器使用的數(shù)據(jù)的存儲器，其中所述處理器可操作為從在包括多個邊緣緩存的內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)中的第一邊緣緩存請求內(nèi)容，從第一邊緣緩存下載至少一些內(nèi)容，當(dāng)?shù)谝贿吘壘彺嫒匀豢晒┦褂脮r，接收數(shù)據(jù)，所述數(shù)據(jù)包括在CDN中基于關(guān)閉第一邊緣緩存的決定使從第一邊緣緩存下載內(nèi)容重新定向為從第二邊緣緩存下載內(nèi)容的第二邊緣緩存的標(biāo)識，并基于第二邊緣緩存的標(biāo)識，從第二邊緣緩存繼續(xù)下載內(nèi)容。
【附圖說明】
[0005]根據(jù)以下詳細(xì)說明，結(jié)合附圖，本發(fā)明應(yīng)當(dāng)?shù)玫礁浞值亓私夂屠斫?，其?
[0006]圖1為根據(jù)本發(fā)明實施方案構(gòu)造且操作的CDN系統(tǒng)的局部圖示、局部方塊圖；
[0007]圖2為用于圖1的CDN系統(tǒng)中具有相對定位符的清單文件的局部圖示、局部方塊圖；
[0008]圖3為用于圖1的CDN系統(tǒng)中具有絕對定位符的清單文件的局部圖示、局部方塊圖；
[0009]圖4為在圖1的⑶N系統(tǒng)中正在關(guān)閉的邊緣緩存的局部圖示、局部方塊圖；
[0010]圖5為在圖1的CDN系統(tǒng)中正在從一個邊緣緩存轉(zhuǎn)移到另一個邊緣緩存的第一客戶端的局部圖示、局部方塊圖；
[0011]圖6為在圖1的CDN系統(tǒng)中正在從一個邊緣緩存轉(zhuǎn)移到另一個邊緣緩存的第二客戶端的局部圖示、局部方塊圖；
[0012]圖7為在圖1的CDN系統(tǒng)中正在從一個邊緣緩存轉(zhuǎn)移到另一個邊緣緩存的第三客戶端的局部圖示、局部方塊圖；
[0013]圖8為在圖1的CDN系統(tǒng)中正在從一個邊緣緩存轉(zhuǎn)移到另一個邊緣緩存的第四客戶端的局部圖示、局部方塊圖 '及
[0014]圖9為在圖1的CDN系統(tǒng)中正在從一個邊緣緩存轉(zhuǎn)移到另一個邊緣緩存的第五客戶端的局部圖示、局部方塊圖。
【具體實施方式】
[0015]作為引言，⑶N通常包括分發(fā)和交付(Dristribut1n&Delivery)組件、服務(wù)路由組件及管理系統(tǒng)。分發(fā)和交付組件通常包括緩存，所述緩存可獲取由終端用戶請求的內(nèi)容，本地化存儲(緩存)所述內(nèi)容及將所述內(nèi)容交付給終端用戶。所述緩存可以以平面或任意分層結(jié)構(gòu)進行組織以使緩存效率最大化。服務(wù)路由組件通常負(fù)責(zé)處理終端用戶的初始內(nèi)容請求(例如，以超文本傳輸協(xié)議(HTTP)內(nèi)容請求、內(nèi)容主機名域名系統(tǒng)(DNS)請求或來自某個外部請求處理系統(tǒng)的應(yīng)用程序編程接口(API)請求的形式)，從分發(fā)和交付組件選擇最適合為請求提供服務(wù)的緩存，以及將終端用戶請求重新定向于選定緩存。
[0016]利用HTTP自適應(yīng)比特率(ABR)(其正在成為主導(dǎo)的內(nèi)容交付格式)，視頻內(nèi)容項分段成許多片段，并且終端用戶客戶端首先請求提供與包括在內(nèi)容項中的片段有關(guān)的信息的清單文件，然后繼續(xù)請求所關(guān)注的下一個片段。當(dāng)由CDN服務(wù)時，初始HTTP ABR清單文件請求此時重新定向至最佳邊緣緩存，然后終端用戶通常從同一個緩存繼續(xù)請求所有片段。最佳邊緣緩存可由一個或一個因素限定，包括(僅作為例子)客戶端與邊緣緩存的接近性、邊緣緩存與客戶端之間的網(wǎng)絡(luò)延遲、邊緣緩存的當(dāng)前備用容量。對于基于硬件的CDN(其中邊緣緩存為持久資源)，所述方法特別適用。
[0017]如果⑶N期望為虛擬化且靈活，那么邊緣緩存可進行高頻率地動態(tài)添加(“⑶N放大”)或移除(“CDN縮小”)，以使所分配資源(CPU、存儲器、存儲裝置、網(wǎng)絡(luò))密切適應(yīng)當(dāng)前負(fù)載，從而使總的內(nèi)容交付成本最小化。
[0018]通過關(guān)閉邊緣緩存使⑶N縮小可能有問題，因為已經(jīng)重新定向至所述邊緣緩存的ABR會話將從同一個緩存繼續(xù)請求后續(xù)內(nèi)容片段，直至視頻/會話結(jié)束(這可能為幾小時，尤其在直播內(nèi)容情況下)，從而明顯推遲虛擬化邊緣緩存的實際移除，從終端用戶角度來看，這通常需要以無中斷方式執(zhí)行。這可能會不必要地保留可以通過其它方式非常快地釋放的資源，例如(但不限于)以秒的順序，使用虛擬化和編排技術(shù)，因此嚴(yán)重限制了靈活虛擬化⑶N的經(jīng)濟效益。
[0019]現(xiàn)在參照圖1，圖1為根據(jù)本發(fā)明實施方案構(gòu)造且操作的⑶N系統(tǒng)10的局部圖示、局部方塊圖。
[0020]應(yīng)當(dāng)理解，為了簡單起見，圖中僅已示出⑶N系統(tǒng)10的某些元件。
[0021]雖然下文已經(jīng)參照ABR系統(tǒng)說明⑶N系統(tǒng)10，但是本領(lǐng)域技術(shù)人員應(yīng)當(dāng)理解，⑶N系統(tǒng)10可利用例如漸進式下載的非ABR內(nèi)容下載系統(tǒng)實現(xiàn)。
[0022]⑶N系統(tǒng)10通常包括⑶N編排功能/系統(tǒng)12、⑶N請求路由器14及多個邊緣緩存16 (包括邊緣緩存I和邊緣緩存2)。
[0023]圖1示出邊緣緩存1，提供內(nèi)容20給多個客戶端18 (包括客戶端I和客戶端2)。每個客戶端18以及下文所述的每個其它客戶端通常包括處理器42和存儲器44。存儲器44可操作為存儲由處理器42使用的數(shù)據(jù)。
[0024]⑶N編排功能12通常包括處理器13和存儲器15。⑶N編排功能12的處理器13一般可操作為監(jiān)測邊緣緩存16，以通過分別添加或移除邊緣緩存16的實例(或多個實例)來判定CDN系統(tǒng)10應(yīng)當(dāng)放大或縮小。僅作為例子，就許多客戶端18如何服務(wù)于每個邊緣緩存16而言，邊緣緩存16的監(jiān)測可通過發(fā)送查詢至邊緣緩存16和/或CDN請求路由器14而實現(xiàn)。邊緣緩存16的處理器30和/或⑶N請求路由器14的處理器22可操作為回應(yīng)于監(jiān)測查詢/多個監(jiān)測查詢，將關(guān)于正在由每個所述邊緣緩存16服務(wù)的客戶端18的數(shù)據(jù)發(fā)送至⑶N編排系統(tǒng)12。應(yīng)當(dāng)理解，⑶N編排功能12的功能可部分或全部在⑶N請求路由器14中實現(xiàn)。
[0025]客戶端18 (客戶端I)的處理器42通常操作為針對內(nèi)容20的清單文件36發(fā)送請求26至⑶N請求路由器14。
[0026]⑶N請求路由器14通常包括處理器22和存儲器24。存儲器24可操作為存儲由處理器22使用的數(shù)據(jù)。⑶N請求路由器14的處理器22通?？刹僮鳛閺目蛻舳?8(圖1中客戶端I)接收內(nèi)容20的清單文件36的“內(nèi)容”請求26 (例如，通常HTTP “獲取”請求)。回應(yīng)于從客戶端18接收內(nèi)容20的清單文件36的請求26，CDN請求路由器14的處理器22通?？刹僮鳛榕卸ㄟ吘壘彺?6中哪一個應(yīng)當(dāng)提供內(nèi)容20的清單文件36給客戶端18 (客戶端I)并將選定邊緣緩存16 (邊緣緩存I)的標(biāo)識28發(fā)送至客戶端18 (客戶端I)，以便客戶端18 (客戶端I)從邊緣緩存16 (邊緣緩存I)檢索清單文件36和內(nèi)容20。應(yīng)當(dāng)理解，選定邊緣緩存16的標(biāo)識28可在包括在HTTP “重新定向”響應(yīng)中的統(tǒng)一資源定位符(URL)內(nèi)進行傳輸。
[0027]客戶端18 (客戶端I)的處理器42通常操作為從⑶N請求路由器14接收標(biāo)識28并發(fā)送清單文件36的請求34至邊緣緩存16 (邊緣緩存I)。
[0028]每個邊緣緩存16通常包括處理器30、存儲器32和緩存存儲器40。存儲器32通?？刹僮鳛榇鎯τ商幚砥?0使用的數(shù)據(jù)。緩存存儲器40通?？刹僮鳛閷?nèi)容20及清單文件36 (視情況)存儲于其中。
[0029]邊緣緩存16 (邊緣緩存I)的處理器30可操作為從客戶端18 (客戶端I)接收清單文件36的請求34。處理器30可操作為發(fā)送/提供清單文件36至客戶端18 (客戶端I)?？蛻舳?8的處理器42可操作為接收清單文件36。
[0030]內(nèi)容20通常包括多個片段64。清單文件36包括每個片段64的位置數(shù)據(jù)。所述位置數(shù)據(jù)指向第一邊緣緩存，其中片段64存儲于第一邊緣緩存中。
[0031]客戶端18(客戶端I)的處理器42可操作為基于存儲于清單文件36中的位置數(shù)據(jù)從邊緣緩存16 (邊緣緩存I)(經(jīng)由請求38)請求內(nèi)容20的每個所關(guān)注片段64。
[0032]邊緣緩存I的處理器30可操作為從客戶端18 (客戶端I)接收內(nèi)容20的相關(guān)片段64的每個內(nèi)容請求38并將存儲于緩存存儲器40中的內(nèi)容20的每個所請求的片段64提供給客戶端18 (客戶端I)。
[0033]客戶端18 (客戶端I)的處理器42可操作為從邊緣緩存16 (邊緣緩存I)下載所請求的片段64 (表示內(nèi)容20的至少一些)。
[0034]用于定位內(nèi)容20的片段的清單文件可包括相對或絕對定位符，將參照圖2和圖3