數(shù)據(jù)請求方法、裝置、節(jié)點服務(wù)器及cdn系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及數(shù)據(jù)容災(zāi)技術(shù)領(lǐng)域，更具體地說，涉及一種數(shù)據(jù)請求方法、裝置以及節(jié)點服務(wù)器及⑶N(Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò))系統(tǒng)。
【背景技術(shù)】
[0002]在現(xiàn)有技術(shù)中，為了提高CDN節(jié)點服務(wù)器資源利用率，以及保持服務(wù)的穩(wěn)定性，越來越多的CDN內(nèi)容分發(fā)系統(tǒng)采用多核多進程的架構(gòu)模型，即在一臺服務(wù)器上運行多個服務(wù)進程，每個服務(wù)進程各自提供內(nèi)容分發(fā)服務(wù)，服務(wù)進程之間運行互不影響，這樣處理，即使其中某個進程異常，也不會影響其他正常工作進程繼續(xù)提供穩(wěn)定的服務(wù)。比如在互聯(lián)網(wǎng)視頻直播業(yè)務(wù)中，CDN網(wǎng)絡(luò)中一臺節(jié)點服務(wù)器上面運行1個服務(wù)進程，各個服務(wù)進程獨自向上一級節(jié)點進行內(nèi)容請求，上一級節(jié)點會將相同的內(nèi)容分別發(fā)送至同一臺服務(wù)器上運行的各個服務(wù)進程，那么，如請求內(nèi)容相同，那么相同的請求內(nèi)容總共會向這臺服務(wù)器發(fā)送10次，造成了上級節(jié)點負荷增大，下行流量的浪費，服務(wù)器自身上行流量的浪費，也增大了自身負荷，同時，由于調(diào)度的處理，10個服務(wù)進程分別向上一級節(jié)點集群請求，由于調(diào)度的原因，其所分配的上級節(jié)點服務(wù)器可能不同，導(dǎo)致各進程請求內(nèi)容分發(fā)時所走路由可能不一致，也可能影響服務(wù)質(zhì)量。
[0003]具體的，如圖1所示，假設(shè)在初始時，CDN節(jié)點服務(wù)器S上服務(wù)進程WorkerM、服務(wù)進程WorkerN上面都沒有內(nèi)容Stream的信息。當服務(wù)進程WorkerM、服務(wù)進程WorkerN先后接收到訪問鏈接請求內(nèi)容Stream時，利用現(xiàn)有技術(shù)的數(shù)據(jù)請求方法執(zhí)行的步驟如下:
[0004]A:⑶N服務(wù)器S上面的服務(wù)進程WorkerM接收訪問鏈接請求，請求內(nèi)容Stream ；
[0005]B:服務(wù)進程WorkerM訪問調(diào)度系統(tǒng)，請求上級節(jié)點服務(wù)器地址；
[0006]C:調(diào)度系統(tǒng)權(quán)衡負載、地理位置等因素，向服務(wù)進程WorkerM返回上級節(jié)點服務(wù)器B的地址。
[0007]D:服務(wù)進程WorkerM獲取上級節(jié)點服務(wù)器B的地址后，向上級節(jié)點服務(wù)器B請求內(nèi)容Str earn，并響應(yīng)鏈接請求；
[0008]E: CDN服務(wù)器S上面的服務(wù)進程WorkerN接收另一路訪問鏈接請求，請求內(nèi)容Stream；
[0009]F:服務(wù)進程WorkerN訪問調(diào)度系統(tǒng)，請求獲取上級節(jié)點服務(wù)器地址；
[0010]G:調(diào)度系統(tǒng)權(quán)衡負載，地理位置等因素，向服務(wù)進程WorkerN返回上級節(jié)點服務(wù)器A(與上級節(jié)點服務(wù)器B處于同一地理位置服務(wù)器集群中，此時服務(wù)器A可能更優(yōu))的地址。
[0011]H:服務(wù)進程WorkerN獲取上級節(jié)點服務(wù)器A的地址后，向上級節(jié)點服務(wù)器A請求內(nèi)容Str earn，并響應(yīng)鏈接請求。
[0012]可見，在現(xiàn)有的CDN系統(tǒng)中，在多服務(wù)進程運行模式下，由于每個服務(wù)進程均會向上級節(jié)點服務(wù)器請求內(nèi)容，在請求內(nèi)容相同的情況下會造成上級節(jié)點服務(wù)器對本服務(wù)器內(nèi)容的重復(fù)發(fā)送，浪費上、下行流量，且增大負荷。
[0013]在一些⑶N服務(wù)商中，通過技術(shù)手段解決了上述重復(fù)請求內(nèi)容的問題，例如在服務(wù)器上部署代理進程專門負責(zé)本地下載進程與上級節(jié)點集群之間的內(nèi)容請求交互處理過程，下載進程接受鏈接后，所有下載進程先訪問代理，代理依據(jù)請求訪問上級節(jié)點集群服務(wù)器，代理從上級節(jié)點獲取內(nèi)容成功后，由代理將內(nèi)容分發(fā)至所有的本地下載請求節(jié)點，由于本地所有下載進程都要訪問代理進程，這容易造成代理進程單點負載過高，從而降低服務(wù)器利用率，并且要開發(fā)代理進程模塊，從而造成成本上升與維護難度增加，從而實際使用效果不佳，同時如果代理進程發(fā)生異常故障，那么所有的下降進程都不能繼續(xù)提供服務(wù)，不利于風(fēng)險控制。
【發(fā)明內(nèi)容】
[0014]本發(fā)明的目的是提供一種數(shù)據(jù)請求方法、裝置、節(jié)點服務(wù)器及⑶N系統(tǒng)，能夠優(yōu)化CDN節(jié)點內(nèi)容路由，避免同個服務(wù)器的不同服務(wù)進程向上級節(jié)點服務(wù)器重復(fù)請求相同內(nèi)容，有效減少鏈路帶寬消耗。
[0015]本發(fā)明實施例提供了一種數(shù)據(jù)請求方法，所述方法應(yīng)用于內(nèi)容分發(fā)網(wǎng)絡(luò)CDN系統(tǒng)中的節(jié)點路由器中，所述方法包括:
[0016]通過本服務(wù)進程接收鏈接請求；
[0017]判斷本地節(jié)點服務(wù)器的本服務(wù)進程是否存在所述鏈接請求的內(nèi)容的信息記錄，若存在，則獲取所述內(nèi)容;否則
[0018]判斷本地節(jié)點服務(wù)器的其他服務(wù)進程是否存在所述鏈接請求的內(nèi)容的信息記錄，若存在，則獲取所述內(nèi)容;否則
[0019]向上級節(jié)點服務(wù)器獲取所述鏈接請求的內(nèi)容；
[0020]基于獲取的內(nèi)容響應(yīng)所述鏈接請求。
[0021 ]作為上述方案的改進，當判斷本地節(jié)點服務(wù)器存在所述鏈接請求的內(nèi)容的信息記錄的其他服務(wù)進程不少于一個時，則選擇當中所述內(nèi)容的鏈接請求數(shù)量最少的服務(wù)進程來獲取所述內(nèi)容。
[0022]作為上述方案的改進，通過查詢本服務(wù)進程維護的單獨內(nèi)容路由表來判斷本地節(jié)點服務(wù)器的本服務(wù)進程是否存在所述鏈接請求的內(nèi)容的信息記錄;其中，所述單獨內(nèi)容路由表記錄相應(yīng)的服務(wù)進程的每一內(nèi)容的信息。
[0023]作為上述方案的改進，通過查詢所有服務(wù)進程共同維護的全局內(nèi)容路由表來判斷本地節(jié)點服務(wù)器的其他服務(wù)進程是否存在所述鏈接請求的內(nèi)容的信息記錄;其中，所述全局內(nèi)容路由表記錄本地節(jié)點路由器的每一服務(wù)進程的每一內(nèi)容的鏈接請求數(shù)量及訪問地址。
[0024]作為上述方案的改進，通過查詢所有服務(wù)進程共同維護的全局內(nèi)容路由表來判斷本地節(jié)點服務(wù)器存在所述鏈接請求的內(nèi)容的信息記錄的其他服務(wù)進程不少于一個時，則選擇當中所述內(nèi)容的鏈接請求數(shù)量最少的服務(wù)進程，并通過對應(yīng)的訪問地址重定向獲取所述內(nèi)容。
[0025]作為上述方案的改進，在判斷本地節(jié)點服務(wù)器的本服務(wù)進程存在所述鏈接請求的內(nèi)容的信息記錄并獲取所述內(nèi)容后，還包括:
[0026]將所述全局內(nèi)容路由表中記錄本服務(wù)進程的所述內(nèi)容的鏈接請求數(shù)量加I，以更新所述全局內(nèi)容路由表。
[0027]作為上述方案的改進，在判斷本地節(jié)點服務(wù)器的其他服務(wù)進程存在所述鏈接請求的內(nèi)容的信息記錄并獲取所述內(nèi)容后，還包括:
[0028]更新所述全局內(nèi)容路由表，將被獲取所述內(nèi)容的服務(wù)進程的所述內(nèi)容的鏈接請求數(shù)量加I，同時將本服務(wù)進程的訪問地址記錄在所述內(nèi)容下，并初始化鏈接請求數(shù)量為I;
[0029]更新本服務(wù)進程的單獨內(nèi)容路由表，增加所述內(nèi)容的信息記錄。
[0030]作為上述方案的改進，所述向上級節(jié)點服務(wù)器獲取所述鏈接請求的內(nèi)容具體為:
[0031]訪問調(diào)度系統(tǒng)，請求獲取上級節(jié)點服務(wù)器的地址；
[0032]接收所述調(diào)度系統(tǒng)返回的上級節(jié)點服務(wù)器地址，并根據(jù)所述上級節(jié)點服務(wù)器地址向所述上級節(jié)點服務(wù)器請求獲取所述鏈接請求的內(nèi)容。
[0033]作為上述方案的改進，在向上級節(jié)點服務(wù)器獲取所述鏈接請求的內(nèi)容后，還包括:
[0034]更新本服務(wù)進程的單獨內(nèi)容路由表，增加所述內(nèi)容的信息記錄；
[0035]更新所述全局內(nèi)容路由表，增加本服務(wù)進程對所述內(nèi)容的鏈接請求，初始化鏈接請求數(shù)量為I，并將本服務(wù)進程的訪問地址記錄在所述內(nèi)容下。
[0036]作為上述方案的改進，還包括:
[0037]當本地節(jié)點服務(wù)的任一服務(wù)進程出現(xiàn)異常時，則通過管理進程向所述全局內(nèi)容路由表進行更新，以清除異常服務(wù)進程的每一內(nèi)容的鏈接請求數(shù)量及訪問地址。
[0038]本發(fā)明實施例對應(yīng)提供了一種數(shù)據(jù)請求裝置，所述裝置應(yīng)用于內(nèi)容分發(fā)網(wǎng)絡(luò)CDN系統(tǒng)中的節(jié)點路由器中，所述裝置包括:
[0039]鏈接請求接收模塊，用于通過本服務(wù)進程接收鏈接請求；
[0040]第一執(zhí)行模塊，用于判斷本地節(jié)點服務(wù)器的本服務(wù)進程是否存在所述鏈接請求的內(nèi)容的信息記錄;若存在，則獲取所述內(nèi)容；
[0041 ]第二執(zhí)行模塊，用于在第一執(zhí)行模塊判斷本地節(jié)點服務(wù)器的本服務(wù)進程不存在所述鏈接請求的內(nèi)容的信息記錄情況下，判斷本地節(jié)點服務(wù)器的其他服務(wù)進程是否存在所述鏈接請求的內(nèi)容的信息記錄，若存在，則獲取所述內(nèi)容；
[0042]第三執(zhí)行模塊，用于在第二執(zhí)行模塊判斷本地節(jié)點服務(wù)器的其他服務(wù)進程不存在所述鏈接請求的內(nèi)容的信息記錄情況下，在向上級節(jié)點服務(wù)器獲取所述鏈接請求的內(nèi)容；
[0043]響應(yīng)模塊，基于獲取的內(nèi)容響應(yīng)所述鏈接請求。
[0044]作為上述方案的改進，所述第二執(zhí)行模塊進一步用于:當判斷本地節(jié)點服務(wù)器存在所述鏈接請求的內(nèi)容的信息記錄的其他服務(wù)進程不少于一個時，則選擇當中所述內(nèi)容的鏈接請求數(shù)量最少的服務(wù)進程來獲取所述內(nèi)容。
[0045]作為上述方案的改進，所述第一執(zhí)行模塊通過查詢本服務(wù)進程維護的單獨內(nèi)容路由表來判斷本地節(jié)