云系統(tǒng)組播文件的方法及裝置的制造方法
【專(zhuān)利摘要】本發(fā)明提供的云系統(tǒng)組播文件的方法及裝置，有效解決了云系統(tǒng)中傳輸大文件到海量的實(shí)例系統(tǒng)時(shí)高帶寬占用率以及整體完成時(shí)間過(guò)長(zhǎng)的問(wèn)題，通過(guò)組播方式傳輸文件，大大降低了帶寬占用。組播的數(shù)據(jù)包中包括了文件偏移量，傳輸?shù)奈募皇軘?shù)據(jù)包亂序的影響。此外，如果組播大范圍失敗，可以在局部系統(tǒng)中選擇一個(gè)實(shí)例系統(tǒng)代表從控制節(jié)點(diǎn)獲取需要傳輸?shù)奈募?，由?shí)例系統(tǒng)代表在局部系統(tǒng)內(nèi)部傳輸，不影響局部系統(tǒng)之外的其他實(shí)例系統(tǒng)。
【專(zhuān)利說(shuō)明】
云系統(tǒng)組播文件的方法及裝置
技術(shù)領(lǐng)域
[0001 ]本發(fā)明涉及云系統(tǒng)組播文件的方法及裝置。
【背景技術(shù)】
[0002]某種操作系統(tǒng)(例如安卓操作系統(tǒng))加上運(yùn)行該操作系統(tǒng)所需的必要硬件(例如處理器、存儲(chǔ)器等)，可以視為一個(gè)實(shí)例系統(tǒng)，實(shí)例系統(tǒng)中可以運(yùn)行各種應(yīng)用(應(yīng)用指能夠在實(shí)例系統(tǒng)的操作系統(tǒng)中運(yùn)行的軟件或程序)。將若干個(gè)實(shí)例系統(tǒng)按照一定的架構(gòu)方式(例如分布式)集中管理，可以形成云系統(tǒng)。通常云系統(tǒng)由運(yùn)營(yíng)商負(fù)責(zé)日常運(yùn)營(yíng)，為用戶(hù)提供服務(wù)。
[0003]很多情況下，運(yùn)營(yíng)商需要把某個(gè)應(yīng)用安裝到大量的實(shí)例系統(tǒng)上，或者對(duì)所有實(shí)例系統(tǒng)的操作系統(tǒng)進(jìn)行升級(jí)(例如該操作系統(tǒng)發(fā)布了重大安全補(bǔ)丁)。目前常見(jiàn)的做法，云系統(tǒng)的控制節(jié)點(diǎn)(例如具有X86架構(gòu)的控制服務(wù)器，用于控制和管理云系統(tǒng)中的實(shí)例系統(tǒng))通過(guò)TCP協(xié)議(Transmiss1n Control Protocol，傳輸控制協(xié)議)多線(xiàn)程并行對(duì)所有的實(shí)例系統(tǒng)推送應(yīng)用安裝包或者操作系統(tǒng)升級(jí)包?；赥CP方式的穩(wěn)定性，運(yùn)營(yíng)商不需要考慮數(shù)據(jù)包丟包或者包亂序的問(wèn)題。但這種做法的缺點(diǎn)也非常明顯，如果需要推送的文件較大，一臺(tái)高性能服務(wù)器同時(shí)推送到幾十個(gè)實(shí)例系統(tǒng)就已經(jīng)達(dá)到上限。即使控制節(jié)點(diǎn)的性能非常強(qiáng)大，并發(fā)推送同一個(gè)大文件到成千上萬(wàn)個(gè)實(shí)例系統(tǒng)，也避免不了大量實(shí)例系統(tǒng)排隊(duì)等待的情況。為了實(shí)現(xiàn)快速推送，可以在云系統(tǒng)中大量配備高性能服務(wù)器，但這非常不經(jīng)濟(jì)。此外，并發(fā)推送大文件會(huì)產(chǎn)生高帶寬占用，可能影響云系統(tǒng)中其他服務(wù)(例如推送音視頻流服務(wù))的流暢運(yùn)行。
[0004]在說(shuō)明書(shū)“【背景技術(shù)】”部分公開(kāi)的內(nèi)容，有助于本領(lǐng)域技術(shù)人員理解本發(fā)明的技術(shù)方案，但不應(yīng)據(jù)此認(rèn)為這些內(nèi)容一定屬于現(xiàn)有技術(shù)或公知常識(shí)。

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

[0005]為了克服“【背景技術(shù)】”部分所反映的缺陷，本發(fā)明提供云系統(tǒng)組播文件的方法及裝置。
[0006]云系統(tǒng)組播文件的方法，包括:
[0007]I)控制節(jié)點(diǎn)分配組播IP與端口號(hào)，通知所有相關(guān)的實(shí)例系統(tǒng)加入組播組。
[0008]2)控制節(jié)點(diǎn)通知存儲(chǔ)模塊加入組播組，以數(shù)據(jù)包形式組播需要傳輸?shù)奈募?br>[0009]3)實(shí)例系統(tǒng)根據(jù)通知?jiǎng)?chuàng)建文件，循環(huán)接收存儲(chǔ)模塊組播的數(shù)據(jù)包。
[0010]進(jìn)一步的，I)中，通知包括需要傳輸?shù)奈募奈募?、文件?yàn)證值、文件大小以及組播組名、端口號(hào)。
[0011 ]進(jìn)一步的，2)中，需要傳輸?shù)奈募环指顬槎鄠€(gè)數(shù)據(jù)塊，組播的數(shù)據(jù)包包括數(shù)據(jù)塊和文件偏移量。
[0012]進(jìn)一步的，3)中，實(shí)例系統(tǒng)將接收的數(shù)據(jù)包中的數(shù)據(jù)塊按照文件偏移量寫(xiě)入創(chuàng)建的文件。
[0013]進(jìn)一步的，3)中，實(shí)例系統(tǒng)每接收一個(gè)數(shù)據(jù)包則實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍。
[0014]更進(jìn)一步的，3)中，如果實(shí)例系統(tǒng)接收數(shù)據(jù)包尚未結(jié)束，實(shí)時(shí)合并的結(jié)果存在至少一處間斷，則實(shí)例系統(tǒng)針對(duì)每處間斷設(shè)定繼續(xù)接收數(shù)據(jù)包的閾值;如果任何一處間斷在實(shí)例系統(tǒng)繼續(xù)接收設(shè)定閾值的數(shù)據(jù)包后仍未被填補(bǔ)，則實(shí)例系統(tǒng)退出組播組。
[0015]云系統(tǒng)組播文件的裝置，包括存儲(chǔ)模塊，存儲(chǔ)模塊用于將需要傳輸?shù)奈募指顬槎鄠€(gè)數(shù)據(jù)塊，生成包括數(shù)據(jù)塊和文件偏移量的數(shù)據(jù)包并組播數(shù)據(jù)包。
[0016]云系統(tǒng)組播文件的裝置，包括實(shí)例系統(tǒng)，實(shí)例系統(tǒng)用于將接收的數(shù)據(jù)包中的數(shù)據(jù)塊按照文件偏移量寫(xiě)入創(chuàng)建的文件，還用于每接收一個(gè)數(shù)據(jù)包則實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍。
[0017]由于云系統(tǒng)組播文件的裝置，與之前所述的云系統(tǒng)組播文件的方法具有明確的關(guān)聯(lián)性，為了避免不必要的重復(fù)，云系統(tǒng)組播文件的裝置中的一些描述進(jìn)行了省略。本領(lǐng)域技術(shù)人員通過(guò)對(duì)照，能夠?qū)υ葡到y(tǒng)組播文件的裝置有清晰、完整的認(rèn)識(shí)。
[0018]云系統(tǒng)組播文件的方法，包括:
[0019]在包括內(nèi)部交換機(jī)和多個(gè)實(shí)例系統(tǒng)的局部系統(tǒng)中選擇一個(gè)實(shí)例系統(tǒng)代表，實(shí)例系統(tǒng)代表從控制節(jié)點(diǎn)獲取需要傳輸?shù)奈募?，在局部系統(tǒng)內(nèi)部傳輸。
[0020]進(jìn)一步的，內(nèi)部傳輸包括實(shí)例系統(tǒng)代表在局部系統(tǒng)中使用控制節(jié)點(diǎn)單獨(dú)分配的組播組內(nèi)部組播。
[0021]本發(fā)明技術(shù)方案中，“包括”、“用于”等詞語(yǔ)應(yīng)按照開(kāi)放式表達(dá)方式理解。本領(lǐng)域技術(shù)人員通過(guò)閱讀本說(shuō)明書(shū)并結(jié)合現(xiàn)有技術(shù)或公知常識(shí)能夠獲知的內(nèi)容，本說(shuō)明書(shū)中不再贅述。
[0022]本發(fā)明提供的云系統(tǒng)組播文件的方法及裝置，有效解決了云系統(tǒng)中傳輸大文件到海量的實(shí)例系統(tǒng)時(shí)高帶寬占用率以及整體完成時(shí)間過(guò)長(zhǎng)的問(wèn)題，通過(guò)組播方式傳輸文件，大大降低了帶寬占用。組播的數(shù)據(jù)包中包括了文件偏移量，傳輸?shù)奈募皇軘?shù)據(jù)包亂序的影響。此外，如果組播大范圍失敗，可以在局部系統(tǒng)中選擇一個(gè)實(shí)例系統(tǒng)代表從控制節(jié)點(diǎn)獲取需要傳輸?shù)奈募蓪?shí)例系統(tǒng)代表在局部系統(tǒng)內(nèi)部傳輸，不影響局部系統(tǒng)之外的其他實(shí)例系統(tǒng)。
【附圖說(shuō)明】
[0023]圖1為【具體實(shí)施方式】中云系統(tǒng)組播文件的方法的流程圖。
[0024]圖2為【具體實(shí)施方式】中云系統(tǒng)的控制節(jié)點(diǎn)、實(shí)例系統(tǒng)和存儲(chǔ)模塊的關(guān)系示意圖。
【具體實(shí)施方式】
[0025]下面對(duì)本發(fā)明的實(shí)施方式進(jìn)行進(jìn)一步的具體說(shuō)明。但應(yīng)注意，本發(fā)明的范圍并不局限于所描述的具體技術(shù)方案。任何對(duì)所描述的具體技術(shù)方案中的技術(shù)要素進(jìn)行相同或等同替換獲得的技術(shù)方案或本領(lǐng)域技術(shù)人員在所描述的具體技術(shù)方案的基礎(chǔ)上不經(jīng)過(guò)創(chuàng)造性勞動(dòng)就可以獲得的技術(shù)方案，都應(yīng)當(dāng)視為落入本發(fā)明的保護(hù)范圍。
[0026]某種操作系統(tǒng)加上運(yùn)行該操作系統(tǒng)所需的必要硬件(例如處理器、存儲(chǔ)器等)，可以構(gòu)成一個(gè)實(shí)例系統(tǒng)。將若干個(gè)實(shí)例系統(tǒng)按照一定的架構(gòu)方式集中管理，可以形成云系統(tǒng)。
[0027]云系統(tǒng)組播文件的方法，采用組播(組播是IP網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)娜N方式之一，在發(fā)送者和每一接收者之間實(shí)現(xiàn)點(diǎn)對(duì)多點(diǎn)網(wǎng)絡(luò)連接)方式來(lái)傳輸文件。這樣云系統(tǒng)的控制節(jié)點(diǎn)(控制節(jié)點(diǎn)用于控制和管理云系統(tǒng)中的全部或部分實(shí)例系統(tǒng)，作為一種實(shí)施方式，由具有X86架構(gòu)的控制服務(wù)器實(shí)現(xiàn))進(jìn)行一次文件傳輸，所有加入了組播組的實(shí)例系統(tǒng)都能接收該文件，大大提高了并行性，同時(shí)降低了網(wǎng)絡(luò)帶寬占用。目前組播只能通過(guò)UDP協(xié)議(UserDatagram Protocol，用戶(hù)數(shù)據(jù)報(bào)協(xié)議)實(shí)現(xiàn)，如果網(wǎng)絡(luò)傳輸質(zhì)量較差，UDP協(xié)議數(shù)據(jù)包丟包會(huì)比較嚴(yán)重。由于云系統(tǒng)傳輸文件使用的是內(nèi)部建立的局域網(wǎng)，網(wǎng)絡(luò)傳輸質(zhì)量很高，不容易丟包，UDP協(xié)議很適合這種場(chǎng)景。當(dāng)然，為了最大可能避免丟包，數(shù)據(jù)包發(fā)送方需要進(jìn)行限速，以便和數(shù)據(jù)包接收方的處理速度匹配，同時(shí)數(shù)據(jù)包接收方要設(shè)置足夠大的socket(當(dāng)網(wǎng)絡(luò)上兩個(gè)程序通過(guò)一個(gè)雙向的通信連接實(shí)現(xiàn)數(shù)據(jù)交換時(shí)，這個(gè)連接的一端稱(chēng)為一個(gè)socket)接收緩存。
[0028]云系統(tǒng)組播文件的方法，如圖1所示，包括如下步驟:
[0029]SlOl:控制節(jié)點(diǎn)分配組播IP與端口號(hào)，通知所有相關(guān)的實(shí)例系統(tǒng)加入組播組。
[0030]具體的，本步驟中，當(dāng)云系統(tǒng)的控制節(jié)點(diǎn)收到傳輸文件(特別是傳輸大文件)到很多個(gè)實(shí)例系統(tǒng)的請(qǐng)求時(shí)，先分配一個(gè)組播IP(組播IP應(yīng)當(dāng)和云系統(tǒng)中已經(jīng)使用的IP不沖突)與端口號(hào)，TCP多線(xiàn)程并行通知所有相關(guān)的實(shí)例系統(tǒng)加入設(shè)置好的組播組，準(zhǔn)備接收數(shù)據(jù)。該TCP通知包括需要傳輸?shù)奈募奈募⑽募?yàn)證值、文件大小(也可以稱(chēng)為文件長(zhǎng)度或文件總長(zhǎng)度)以及組播組名、端口號(hào)等信息，其中文件驗(yàn)證值常選用MD5(消息摘要算法第五版，為廣泛使用的一種散列函數(shù)，用以提供消息的完整性保護(hù))。實(shí)際中往往會(huì)有控制節(jié)點(diǎn)認(rèn)為某個(gè)實(shí)例系統(tǒng)需要接收某個(gè)文件而該實(shí)例系統(tǒng)中已經(jīng)存在該文件的情況，因此實(shí)例系統(tǒng)收到TCP通知后，可以將其中的信息與實(shí)例系統(tǒng)的存儲(chǔ)器上已有的文件進(jìn)行比對(duì)，如果存儲(chǔ)器上的某個(gè)文件與TCP通知中需要傳輸?shù)奈募奈募?、MD5、文件大小三者都相同，則該實(shí)例系統(tǒng)直接退出組播組并報(bào)告控制節(jié)點(diǎn)接收成功，這樣可以避免無(wú)意義的文件傳輸，節(jié)約云系統(tǒng)的資源。
[0031]S102:控制節(jié)點(diǎn)通知存儲(chǔ)模塊加入組播組，以數(shù)據(jù)包形式組播需要傳輸?shù)奈募?br>[0032]具體的，本步驟中，控制節(jié)點(diǎn)通知存儲(chǔ)模塊加入組播組。通常，存儲(chǔ)模塊位于云系統(tǒng)中獨(dú)立的高性能存儲(chǔ)服務(wù)器(存儲(chǔ)服務(wù)器一般具有較高的配置，例如8核處理器、64G大內(nèi)存等)上，存儲(chǔ)了需要傳輸給很多個(gè)實(shí)例系統(tǒng)的文件(特別是大文件)。存儲(chǔ)模塊將需要傳輸?shù)奈募指顬槎鄠€(gè)數(shù)據(jù)塊，生成數(shù)據(jù)包(UDP包)。每個(gè)數(shù)據(jù)包都包括數(shù)據(jù)塊和文件偏移量(從指定位置向前或向后移動(dòng)的字節(jié)數(shù))，為了盡可能方便的實(shí)現(xiàn)本發(fā)明技術(shù)方案，數(shù)據(jù)包中往往還包括數(shù)據(jù)塊大小(也可以稱(chēng)為數(shù)據(jù)塊長(zhǎng)度)。存儲(chǔ)模塊組播需要傳輸?shù)奈募瑢?shí)質(zhì)上是組播UDP包。如果所有的UDP包發(fā)送完成，則存儲(chǔ)模塊退出組播組，并報(bào)告控制節(jié)點(diǎn)發(fā)送成功。反之，如果因磁盤(pán)10異常等情況導(dǎo)致UDP包發(fā)送失敗，則存儲(chǔ)模塊退出組播組，并報(bào)告控制節(jié)點(diǎn)發(fā)送失敗。
[0033]S103:實(shí)例系統(tǒng)根據(jù)通知?jiǎng)?chuàng)建文件，循環(huán)接收存儲(chǔ)模塊組播的數(shù)據(jù)包。
[0034]具體的，本步驟中，實(shí)例系統(tǒng)根據(jù)之前收到的TCP通知，在實(shí)例系統(tǒng)的存儲(chǔ)器上選擇合適的位置，按照文件名和文件大小創(chuàng)建一個(gè)新文件。實(shí)例系統(tǒng)不斷重復(fù)接收數(shù)據(jù)包的操作，循環(huán)接收組播的數(shù)據(jù)包(UDP包)。為了避免循環(huán)接收導(dǎo)致無(wú)限等待UDP包，實(shí)例系統(tǒng)可以設(shè)置socket接收時(shí)限，如果超過(guò)時(shí)限仍未收到UDP包則認(rèn)為UDP包的發(fā)送已經(jīng)終止或失敗，接收UDP包的過(guò)程結(jié)束。
[0035]對(duì)于接收的UDP包，實(shí)例系統(tǒng)將UDP包中的數(shù)據(jù)塊直接按照文件偏移量寫(xiě)入創(chuàng)建的文件。由于UDP包中附帶了文件偏移量，數(shù)據(jù)塊能夠?qū)懭胝_的位置，UDP包出現(xiàn)亂序?qū)?shí)例系統(tǒng)接收文件沒(méi)有影響。同時(shí)，實(shí)例系統(tǒng)每接收一個(gè)數(shù)據(jù)包，則實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍。正常情況下，UDP包是按照數(shù)據(jù)塊在需要傳輸?shù)奈募械南群箜樞蛞来伟l(fā)送的，實(shí)時(shí)合并的結(jié)果就是從文件起始位置到當(dāng)前偏移(中間沒(méi)有間斷)。如果合并的結(jié)果是從文件起始位置到文件結(jié)尾位置(由于文件大小已知，每個(gè)數(shù)據(jù)塊的文件偏移量和數(shù)據(jù)塊大小也已知，很容易計(jì)算出是否已經(jīng)達(dá)到文件結(jié)尾位置)，中間沒(méi)有間斷，則意味著所有的UDP包都已接收，接收UDP包的過(guò)程結(jié)束。
[0036]考慮到UDP包可能存在亂序或丟包情況，為了避免文件傳輸錯(cuò)誤，設(shè)置這樣一個(gè)判斷規(guī)則:如果實(shí)例系統(tǒng)接收UDP包的過(guò)程尚未結(jié)束，實(shí)時(shí)合并的結(jié)果存在至少一處間斷，則實(shí)例系統(tǒng)針對(duì)每處間斷設(shè)定繼續(xù)接收UDP包的閾值;如果任何一處間斷在實(shí)例系統(tǒng)繼續(xù)接收設(shè)定閾值的UDP包后仍未被填補(bǔ)，則實(shí)例系統(tǒng)退出組播組并報(bào)告控制節(jié)點(diǎn)接收失敗。設(shè)置這個(gè)判斷規(guī)則基于如下考慮:由于UDP包在組播過(guò)程中可能亂序，實(shí)時(shí)合并的結(jié)果如果存在間斷，間斷可能會(huì)被后來(lái)接收的遲到UDP包填補(bǔ)。但如果實(shí)例系統(tǒng)繼續(xù)接收一定數(shù)量的UDP包后間斷仍未被填補(bǔ)，則意味著可能UDP包的發(fā)送速度遠(yuǎn)大于實(shí)例系統(tǒng)的接收速度，或者實(shí)例系統(tǒng)的處理器被別的進(jìn)程大量占用，UDP包已經(jīng)丟包，間斷后續(xù)再被填補(bǔ)的可能性不大。繼續(xù)接收UDP包的閾值，可根據(jù)存儲(chǔ)模塊分割形成的UDP包的數(shù)量、網(wǎng)絡(luò)情況等因素綜合考慮設(shè)定。如果實(shí)時(shí)合并的結(jié)果存在多于一處的間斷，可以為不同間斷設(shè)定不同的繼續(xù)接收UDP包的閾值，當(dāng)然通常情況下對(duì)不同間斷設(shè)定相同的閾值是簡(jiǎn)單而有效的。
[0037]注意，設(shè)置socket接收時(shí)限和設(shè)定繼續(xù)接收UDP包的閾值這兩個(gè)條件要同時(shí)使用。例如，實(shí)時(shí)合并的結(jié)果是從文件起始位置到文件結(jié)尾位置，但存在至少一處間斷，超過(guò)設(shè)置的socket接收時(shí)限仍未接收到UDP包，則最可能的原因是UDP包的發(fā)送已經(jīng)結(jié)束，確實(shí)存在丟包，文件傳輸失敗。
[0038]實(shí)時(shí)合并的結(jié)果是從文件起始位置到文件結(jié)尾位置，也不存在間斷，并不意味著文件傳輸就一定成功了，實(shí)例系統(tǒng)還要檢查創(chuàng)建的文件的文件大小和MD5是否和TCP通知中需要傳輸?shù)奈募奈募笮『蚆D5—致，兩者都一致，文件才算真正的傳輸成功，否則仍視為傳輸失敗。無(wú)論最終的結(jié)果是文件傳輸成功還是失敗，實(shí)例系統(tǒng)都將相應(yīng)的結(jié)果通知控制節(jié)點(diǎn)。
[0039]下面通過(guò)一個(gè)理想化的簡(jiǎn)單示例進(jìn)一步展示S102和S103的工作過(guò)程。實(shí)例系統(tǒng)收到的TCP通知顯示需要傳輸一個(gè)名稱(chēng)為ust、大小5KB的文件，則實(shí)例系統(tǒng)在存儲(chǔ)器上選擇合適的位置，創(chuàng)建一個(gè)名稱(chēng)為ust、大小5KB的新文件。實(shí)例系統(tǒng)設(shè)置socket接收時(shí)限為2秒。
[0040]存儲(chǔ)模塊將需要傳輸?shù)膗st文件分割為5個(gè)數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊IKB，生成5個(gè)UDP包，每個(gè)UDP包中包括IKB的數(shù)據(jù)塊和文件偏移量(從ust的起始位置計(jì)算，分別為0K、IK、2K、3K、4K)0
[0041 ] 情形1:正常情況，存儲(chǔ)模塊按照文件偏移量0Κ、1Κ、2Κ、3Κ、4Κ的順序發(fā)送UDP包，實(shí)例系統(tǒng)也按照文件偏移量OK、IK、2Κ、3Κ、4Κ的順序接收UDP包。
[0042]實(shí)例系統(tǒng)接收文件偏移量OK的UDP包，按照文件偏移量從創(chuàng)建的ust文件的起始位置寫(xiě)入數(shù)據(jù)塊，并實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍，實(shí)時(shí)合并的結(jié)果是創(chuàng)建的ust文件OK到IK的范圍被寫(xiě)入數(shù)據(jù);實(shí)例系統(tǒng)接收文件偏移量IK的UDP包，按照文件偏移量從距離創(chuàng)建的USt文件起始位置IK的位置寫(xiě)入數(shù)據(jù)塊，并實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍，實(shí)時(shí)合并的結(jié)果是創(chuàng)建的ust文件OK到2K的范圍被寫(xiě)入數(shù)據(jù)，中間無(wú)間斷。依次類(lèi)推，當(dāng)實(shí)例系統(tǒng)接收5個(gè)UDP包后，創(chuàng)建的ust文件OK到5K的范圍都被寫(xiě)入數(shù)據(jù)，中間無(wú)間斷，這意味著所有的UDP包都已接收，接收UDP包的過(guò)程結(jié)束。實(shí)例系統(tǒng)還要檢查創(chuàng)建的ust文件的大小和MD5是否和TCP通知中ust文件的大小和MD5—致，兩者都一致，文件傳輸成功。
[0043]情形2:1]0?包亂序，存儲(chǔ)模塊按照文件偏移量01(、11(、21(、31(、41(的順序發(fā)送1]0?包，實(shí)例系統(tǒng)卻按照文件偏移量OK、IK、3K、4K、2K的順序接收UDP包。
[0044]實(shí)例系統(tǒng)接收文件偏移量3K的UDP包后，實(shí)時(shí)合并的結(jié)果發(fā)現(xiàn)創(chuàng)建的ust文件OK到4K的范圍被寫(xiě)入數(shù)據(jù)，但中間存在2K到3K這個(gè)間斷。實(shí)例系統(tǒng)設(shè)定繼續(xù)接收UDP包的閾值為2個(gè)UDP包。在文件偏移量3K的UDP包后，實(shí)例系統(tǒng)后續(xù)又接收了文件偏移量4K、2K的UDP包，由于在設(shè)定的閾值范圍內(nèi)收到了文件偏移量2Κ的UDP包，2Κ到3Κ的間斷能夠被填補(bǔ)上。
[0045]情形3:1]0?包丟包，存儲(chǔ)模塊按照文件偏移量01(、11(、21(、31(、41(的順序發(fā)送1]0?包，實(shí)例系統(tǒng)卻只收到按照文件偏移量OK、IK、3Κ、4Κ的UDP包，文件偏移量2Κ的UDP包丟包。
[0046]實(shí)例系統(tǒng)接收文件偏移量3Κ的UDP包后，實(shí)時(shí)合并的結(jié)果發(fā)現(xiàn)創(chuàng)建的ust文件OK到4Κ的范圍被寫(xiě)入數(shù)據(jù)，但中間存在2Κ到3Κ這個(gè)間斷。實(shí)例系統(tǒng)同樣設(shè)定繼續(xù)接收UDP包的閾值為2個(gè)UDP包，但后續(xù)實(shí)例系統(tǒng)只接收了文件偏移量4Κ的UDP包，超過(guò)設(shè)置的socket接收時(shí)限2秒后仍然沒(méi)有收到文件偏移量2K的UDP包，2K到3K的間斷沒(méi)有被填補(bǔ)上。這時(shí)實(shí)例系統(tǒng)沒(méi)有必要繼續(xù)等待UDP包，可以認(rèn)為文件傳輸已經(jīng)失敗，立即向控制節(jié)點(diǎn)報(bào)告。
[0047]利用云系統(tǒng)組播文件的裝置，可以實(shí)現(xiàn)以上所述的云系統(tǒng)組播文件的方法。云系統(tǒng)組播文件的裝置，包括云系統(tǒng)中的控制節(jié)點(diǎn)、實(shí)例系統(tǒng)和存儲(chǔ)模塊(一般位于云系統(tǒng)中獨(dú)立的存儲(chǔ)服務(wù)器上)三個(gè)部件。存儲(chǔ)模塊與實(shí)例系統(tǒng)彼此獨(dú)立，都由控制節(jié)點(diǎn)控制和管理，其關(guān)系如圖2所示(圖2中的實(shí)線(xiàn)雙向箭頭表示控制和管理關(guān)系，虛線(xiàn)箭頭表示組播中的數(shù)據(jù)流向)。存儲(chǔ)模塊比較重要的功能，是將需要傳輸?shù)奈募指顬槎鄠€(gè)數(shù)據(jù)塊，生成包括數(shù)據(jù)塊和文件偏移量的數(shù)據(jù)包，并組播數(shù)據(jù)包。實(shí)例系統(tǒng)比較重要的功能，一是將接收的數(shù)據(jù)包中的數(shù)據(jù)塊按照文件偏移量寫(xiě)入創(chuàng)建的文件，二是每接收一個(gè)數(shù)據(jù)包則實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍。上述功能都可以通過(guò)編寫(xiě)專(zhuān)用程序?qū)崿F(xiàn)。
[0048]正常情況下，一次組播所有相關(guān)的實(shí)例系統(tǒng)都可以成功接收需要傳輸?shù)奈募?，如果有個(gè)別實(shí)例系統(tǒng)由于自身原因(例如組播時(shí)恰好負(fù)荷過(guò)重)導(dǎo)致接收文件失敗，控制節(jié)點(diǎn)可以對(duì)這些實(shí)例系統(tǒng)單獨(dú)采用TCP方式重新傳輸文件，接收文件失敗的實(shí)例系統(tǒng)數(shù)量很少時(shí)，TCP重新傳輸不會(huì)對(duì)云系統(tǒng)的整體性能有較大影響。但在一些極端情況下，組播大范圍失敗，這時(shí)就需要采用特殊的云系統(tǒng)組播文件的方法。
[0049]在整體的云系統(tǒng)中，還可以設(shè)置一些局部系統(tǒng)，局部系統(tǒng)中包括內(nèi)部交換機(jī)和多個(gè)實(shí)例系統(tǒng)(例如I個(gè)內(nèi)部交換機(jī)和24個(gè)小型實(shí)例系統(tǒng)可以組成一臺(tái)刀片服務(wù)器，這臺(tái)刀片服務(wù)器就可以視為一個(gè)局部系統(tǒng))，局部系統(tǒng)中的內(nèi)部交換機(jī)進(jìn)行網(wǎng)絡(luò)傳輸時(shí)數(shù)據(jù)不會(huì)外溢到局部系統(tǒng)之外的其他實(shí)例系統(tǒng)。局部系統(tǒng)可以選擇其中的一個(gè)實(shí)例系統(tǒng)作為代表，從控制節(jié)點(diǎn)以TCP方式獲取需要傳輸?shù)奈募缓笤诰植肯到y(tǒng)內(nèi)部傳輸。具體的內(nèi)部傳輸方法有兩種，一種是控制節(jié)點(diǎn)為這個(gè)局部系統(tǒng)單獨(dú)分配一個(gè)組播組，實(shí)例系統(tǒng)代表在局部系統(tǒng)中利用單獨(dú)分配的組播組進(jìn)行內(nèi)部組播(組播不面向局部系統(tǒng)之外的實(shí)例系統(tǒng))；另一種是實(shí)例系統(tǒng)代表將要傳輸?shù)奈募訲CP方式發(fā)送給另一個(gè)實(shí)例系統(tǒng)，這兩個(gè)實(shí)例系統(tǒng)同時(shí)再把要傳輸?shù)奈募訲CP方式發(fā)送給另外兩個(gè)實(shí)例系統(tǒng)，以這種“一變二、二變四、四變八……”的模式指數(shù)級(jí)的在局部系統(tǒng)內(nèi)傳輸文件。當(dāng)局部系統(tǒng)中的實(shí)例系統(tǒng)較多時(shí)，第一種方法較為適宜；當(dāng)局部系統(tǒng)中的實(shí)例系統(tǒng)較少時(shí)，第二種方法較為適宜。
[0050]本發(fā)明技術(shù)方案，將要傳輸?shù)奈募纸鉃閁DP包，組播UDP包，大大降低了帶寬占用。但對(duì)于一些關(guān)鍵性且數(shù)據(jù)量很少的參數(shù)(例如需要傳輸?shù)奈募奈募⑽募?yàn)證值、文件大小以及組播組名、端口號(hào))，仍然采用TCP傳輸，確保這些參數(shù)傳輸?shù)臏?zhǔn)確性。UDP包中包括了數(shù)據(jù)塊和文件偏移量，還可以包括數(shù)據(jù)塊大小，組播UDP包不受UDP包亂序的影響。通過(guò)實(shí)時(shí)合并所有已經(jīng)接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍，可以及時(shí)發(fā)現(xiàn)UDP包較為嚴(yán)重的丟包問(wèn)題。此外，如果組播大范圍失敗，則充分利用云系統(tǒng)中的局部系統(tǒng)性能自治的優(yōu)勢(shì)，在局部系統(tǒng)內(nèi)部完成文件的傳輸。
[0051 ]如果利用“【背景技術(shù)】”部分所述的常見(jiàn)做法將一個(gè)大文件傳輸?shù)綆浊€(gè)實(shí)例系統(tǒng)，估算的時(shí)間需要幾個(gè)小時(shí)，而利用本發(fā)明技術(shù)方案則只需要幾分鐘。本發(fā)明技術(shù)方案的時(shí)間復(fù)雜度由線(xiàn)性降低為常數(shù)，這意味著并不需要隨著實(shí)例系統(tǒng)數(shù)量的增加而增加控制節(jié)點(diǎn)，同時(shí)網(wǎng)絡(luò)帶寬的占用率也大大降低。
[0052]本領(lǐng)域技術(shù)人員在以上所描述的具體技術(shù)方案的基礎(chǔ)上，完全可以構(gòu)造出其他方案，在此不--列舉。
【主權(quán)項(xiàng)】
1.云系統(tǒng)組播文件的方法，其特征在于，所述的方法包括: 1)控制節(jié)點(diǎn)分配組播IP與端口號(hào)，通知所有相關(guān)的實(shí)例系統(tǒng)加入組播組； 2)控制節(jié)點(diǎn)通知存儲(chǔ)模塊加入組播組，以數(shù)據(jù)包形式組播需要傳輸?shù)奈募?3)實(shí)例系統(tǒng)根據(jù)通知?jiǎng)?chuàng)建文件，循環(huán)接收存儲(chǔ)模塊組播的數(shù)據(jù)包。2.根據(jù)權(quán)利要求1所述的方法，其特征在于，I)中所述的通知包括需要傳輸?shù)奈募奈募⑽募?yàn)證值、文件大小以及組播組名、端口號(hào)。3.根據(jù)權(quán)利要求1所述的方法，其特征在于，2)中所述的需要傳輸?shù)奈募环指顬槎鄠€(gè)數(shù)據(jù)塊，組播的數(shù)據(jù)包包括數(shù)據(jù)塊和文件偏移量。4.根據(jù)權(quán)利要求1所述的方法，其特征在于，3)中所述的實(shí)例系統(tǒng)將接收的數(shù)據(jù)包中的數(shù)據(jù)塊按照文件偏移量寫(xiě)入創(chuàng)建的文件。5.根據(jù)權(quán)利要求1所述的方法，其特征在于，3)中所述的實(shí)例系統(tǒng)每接收一個(gè)數(shù)據(jù)包則實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍。6.根據(jù)權(quán)利要求3所述的方法，其特征在于，3)中如果所述的實(shí)例系統(tǒng)接收數(shù)據(jù)包尚未結(jié)束，實(shí)時(shí)合并的結(jié)果存在至少一處間斷，則所述的實(shí)例系統(tǒng)針對(duì)每處間斷設(shè)定繼續(xù)接收數(shù)據(jù)包的閾值;如果任何一處間斷在所述的實(shí)例系統(tǒng)繼續(xù)接收設(shè)定閾值的數(shù)據(jù)包后仍未被填補(bǔ)，則所述的實(shí)例系統(tǒng)退出組播組。7.云系統(tǒng)組播文件的裝置，包括存儲(chǔ)模塊，其特征在于，所述的存儲(chǔ)模塊用于將需要傳輸?shù)奈募指顬槎鄠€(gè)數(shù)據(jù)塊，生成包括數(shù)據(jù)塊和文件偏移量的數(shù)據(jù)包并組播數(shù)據(jù)包。8.云系統(tǒng)組播文件的裝置，包括實(shí)例系統(tǒng)，其特征在于，所述的實(shí)例系統(tǒng)用于將接收的數(shù)據(jù)包中的數(shù)據(jù)塊按照文件偏移量寫(xiě)入創(chuàng)建的文件，還用于每接收一個(gè)數(shù)據(jù)包則實(shí)時(shí)合并所有已接收的數(shù)據(jù)塊在創(chuàng)建的文件中的范圍。9.云系統(tǒng)組播文件的方法，其特征在于，所述的方法包括: 在包括內(nèi)部交換機(jī)和多個(gè)實(shí)例系統(tǒng)的局部系統(tǒng)中選擇一個(gè)實(shí)例系統(tǒng)代表，實(shí)例系統(tǒng)代表從控制節(jié)點(diǎn)獲取需要傳輸?shù)奈募?，在局部系統(tǒng)內(nèi)部傳輸。10.根據(jù)權(quán)利要求9所述的方法，其特征在于，所述的內(nèi)部傳輸包括實(shí)例系統(tǒng)代表在局部系統(tǒng)中使用控制節(jié)點(diǎn)單獨(dú)分配的組播組內(nèi)部組播。
【文檔編號(hào)】H04L29/12GK106059936SQ201610652428
【公開(kāi)日】2016年10月26日
【申請(qǐng)日】2016年8月10日 公開(kāi)號(hào)201610652428.3, CN 106059936 A, CN 106059936A, CN 201610652428, CN-A-106059936, CN106059936 A, CN106059936A, CN201610652428, CN201610652428.3
【發(fā)明人】王小品, 田樂(lè), 趙一民
【申請(qǐng)人】北京海譽(yù)動(dòng)想科技股份有限公司