Lxpfs集群分布式文件存儲(chǔ)系統(tǒng)的制作方法
【專利摘要】LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，采用LXPFS集群給應(yīng)用提供訪問(wèn)方法，通過(guò)封裝好的JS API訪問(wèn)LXPFS中的文件；訪問(wèn)LXPFS文件的方式分為三種：讀、寫和刪除；在前端實(shí)現(xiàn)訪問(wèn)LXPFS文件的組件，在Web應(yīng)用開發(fā)中只需生成一個(gè)組件，調(diào)用相應(yīng)的接口就能實(shí)現(xiàn)訪問(wèn)；系統(tǒng)采用主從模式架構(gòu)，由一個(gè)Dispatchnode和一個(gè)及以上的Tasknode組成；Dispatchnode是一個(gè)controller服務(wù)器，負(fù)責(zé)調(diào)配所有文件的存儲(chǔ)以及處理并轉(zhuǎn)發(fā)客戶端的請(qǐng)求，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)和響應(yīng)客戶端的請(qǐng)求；上傳文件是將數(shù)據(jù)寫入Tasknode中，下載文件則是讀取Tasknode文件數(shù)據(jù)。本系統(tǒng)采用對(duì)大文件分割的方式進(jìn)行上傳，對(duì)上傳的文件沒(méi)有大小限制，解決了大容量存儲(chǔ)、分布存儲(chǔ)、負(fù)載均衡等問(wèn)題，它以服務(wù)的方式提供Web服務(wù)器一個(gè)文件管理組件的功能。
【專利說(shuō)明】
LXPFS集群分布式文件存儲(chǔ)系統(tǒng)
技術(shù)領(lǐng)域
[0001 ]本發(fā)明用于解決Web服務(wù)項(xiàng)目對(duì)文件訪問(wèn)和文件的存儲(chǔ)，具體涉及LXPFS集群分布式文件存儲(chǔ)系統(tǒng)的技術(shù)領(lǐng)域。
【背景技術(shù)】
[0002]基于Web技術(shù)的應(yīng)用系統(tǒng)，由于開發(fā)周期短，與用戶平臺(tái)無(wú)關(guān)，易于實(shí)現(xiàn)交互應(yīng)用，能對(duì)信息進(jìn)行快速、高效地收集、處理和發(fā)布，近幾年來(lái)得到了快速發(fā)展。
[0003]數(shù)據(jù)對(duì)于應(yīng)用是很重要的，可以這么說(shuō)幾乎所有的應(yīng)用系統(tǒng)開發(fā)都是圍繞著數(shù)據(jù)進(jìn)行的，Web應(yīng)用系統(tǒng)也不例外。在用戶使用的過(guò)程中，應(yīng)用系統(tǒng)在用戶需要時(shí)提供數(shù)據(jù)。Web系統(tǒng)在與用戶交互，其實(shí)也是一個(gè)數(shù)據(jù)交換過(guò)程。應(yīng)用系統(tǒng)的數(shù)據(jù)主要保存在數(shù)據(jù)庫(kù)和文件里，然而數(shù)據(jù)庫(kù)也是基于文件的。應(yīng)用系統(tǒng)的信息數(shù)據(jù)一般是保存在數(shù)據(jù)庫(kù)里，大的數(shù)據(jù)則保存在文件里。所以文件管理系統(tǒng)對(duì)于Web應(yīng)用同樣是一個(gè)基礎(chǔ)而重要的功能模塊之
O
[0004]為了方便用戶的使用，Web應(yīng)用一般提供三種對(duì)文件的訪問(wèn)方式，上傳、下載和刪除，也可以說(shuō)寫入、讀取和刪除。文件上傳存在多種技術(shù)，常見(jiàn)的有:基于JS框架提供的上傳組件;基于數(shù)據(jù)庫(kù)技術(shù);使用控件進(jìn)行上傳;使用其他的上傳組件等。使用JS框架提供的上傳組件，代碼的可重用性變得異常差。多個(gè)使用不同JS框架開發(fā)的Web應(yīng)用服務(wù)系統(tǒng)，就存在多個(gè)不同版本的文件管理功能模塊?；跀?shù)據(jù)庫(kù)的上傳，一般是將文件保存在數(shù)據(jù)庫(kù)里。這種方式雖然能夠提高文件的索引，便于維護(hù)和管理，但對(duì)于存儲(chǔ)空間的浪費(fèi)也是很突出的。使用不同的上傳技術(shù)，都會(huì)有不同的弊端。相比傳統(tǒng)的上傳技術(shù)，LXPFS(LinuxXProgram File System)在減少弊端和完善。
[0005]很多Web上傳都對(duì)大文件上傳做了限制，這是因?yàn)樯蟼魑募^(guò)大，Http上傳請(qǐng)求會(huì)長(zhǎng)時(shí)間占用資源，可能致使瀏覽器掛死。為了實(shí)現(xiàn)克服大文件的上傳，于是又出現(xiàn)了使用控件的方法。比如網(wǎng)頁(yè)版的百度網(wǎng)盤和360網(wǎng)盤，在用戶上傳的文件大小超過(guò)限制時(shí)，會(huì)提示用戶安裝控件。雖然使用控件實(shí)現(xiàn)了大文件的上傳，但是它增加了開發(fā)難度和提高了開發(fā)成本，我們必須針對(duì)不同的平臺(tái)系統(tǒng)和不同的瀏覽器開發(fā)不同版本的控件，這顯然不為開發(fā)人員所樂(lè)見(jiàn)。一些專業(yè)的團(tuán)隊(duì)開發(fā)了上傳的組件，它相比以上任何上傳技術(shù)都有很大的進(jìn)步性，可是每個(gè)使用這些上傳組件的系統(tǒng)都是孤立的。這些孤立的系統(tǒng)就如孤島一樣，資源無(wú)法共享沒(méi)有被有效利用。
[0006]LXPFS采用文件分片上傳的方式，實(shí)現(xiàn)了大文件的上傳。并且在前端實(shí)現(xiàn)中，未引入任何JS框架，這樣提高了 Web應(yīng)用系統(tǒng)的兼容，減少了對(duì)Web應(yīng)用開發(fā)的技術(shù)限制。在前端只是實(shí)現(xiàn)了基本的上傳組件功能，所有的界面展示交由Web應(yīng)用，這種方式相比有些上傳組件更加靈活。LXPFS采用了秒傳技術(shù)，提高上傳效率，很多上傳組件也有所實(shí)現(xiàn)，但是LXPFS相比組件而言，它是一個(gè)服務(wù)系統(tǒng)。它給每個(gè)Web應(yīng)用服務(wù)系統(tǒng)提供一個(gè)文件訪問(wèn)的組件功能，允許多系統(tǒng)接入，它同時(shí)存儲(chǔ)多個(gè)應(yīng)用系統(tǒng)的數(shù)據(jù)，擴(kuò)大了文件共享的范圍，增加了秒傳的機(jī)率。并且LXPFS對(duì)應(yīng)用系統(tǒng)的數(shù)據(jù)又做了相應(yīng)的隔離，對(duì)于安全有很好的保障。它打破了上傳組件的孤島模式。
[0007]LXPFS是一個(gè)輕量級(jí)分布式存儲(chǔ)系統(tǒng)，相比Hadoop、tf s等分布式存儲(chǔ)系統(tǒng)而言，LXPFS在安全方面做了特殊的限制，并且它主要是面向Web應(yīng)用開發(fā)。它旨在提高文件的上傳效率，實(shí)現(xiàn)交互信息很少而可做的操作很多。相比其他的分布式文件存儲(chǔ)系統(tǒng)，它更偏重于降低Web應(yīng)用系統(tǒng)對(duì)于文件管理模塊功能的開發(fā)難度，統(tǒng)一多個(gè)應(yīng)用系統(tǒng)的文件管理開發(fā)，同時(shí)減少Web應(yīng)用服務(wù)系統(tǒng)對(duì)于文件管理模塊的運(yùn)維成本。并且它多種備份策略，是從集群HA(高可用)架構(gòu)和文件的特殊存儲(chǔ)方式等多方面來(lái)實(shí)現(xiàn)的。在集群架構(gòu)的節(jié)點(diǎn)的功能劃分也是不同的。

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

[0008]為了避免應(yīng)用的重復(fù)性開發(fā)，一般的做法是把功能模塊進(jìn)行抽象，形成一個(gè)獨(dú)立的組件，并提供相應(yīng)的接口進(jìn)行調(diào)用。LXPFS是一個(gè)輕量級(jí)的分布式文件存儲(chǔ)系統(tǒng)，它以服務(wù)的方式提供給Web應(yīng)用一個(gè)文件存儲(chǔ)管理的功能組件，因此它允許多個(gè)Web應(yīng)用接入，而LXPFS則會(huì)接管這些Web應(yīng)用的文件管理的工作。LXPFS的出現(xiàn)降低了開發(fā)的難度，減少了開發(fā)成本。對(duì)比文件管理組件，LXPFS統(tǒng)一管理多應(yīng)用的文件，擴(kuò)大了文件共享池的范圍，增加了秒傳的機(jī)率，使上傳效率有很大提高，同時(shí)也降低了 Web應(yīng)用中的文件管理的運(yùn)維成本。
[0009]I組件服務(wù)
[0010]LXPFS給應(yīng)用提供了訪問(wèn)方法，可以通過(guò)封裝好的JS API訪問(wèn)LXPFS中的文件。訪問(wèn)LXPFS文件的方式分為三種，讀、寫和刪除。我們已經(jīng)在前端實(shí)現(xiàn)了訪問(wèn)LXPFS文件的組件，在Web應(yīng)用開發(fā)中，只需要生成一個(gè)組件，調(diào)用相應(yīng)的接口就可以實(shí)現(xiàn)訪問(wèn)。
[0011 ]組件分為三個(gè)功能模塊，上傳功能、下載功能和刪除功能。上傳文件是寫入LXPFS集群Tasknode數(shù)據(jù)的一種方式，而下載文件則是讀取Tasknode文件數(shù)據(jù)的一種方式。
[0012]上傳組件服務(wù)被封裝成一個(gè)實(shí)體類QFi IeUpload。每個(gè)QFi IeUpload實(shí)體類中維護(hù)著一個(gè)上傳隊(duì)列。上傳之前需要先選擇本地文件，選擇的一個(gè)本地文件將被封裝成一個(gè)上傳任務(wù)對(duì)象，并被自動(dòng)添加到上傳任務(wù)隊(duì)列里。上傳任務(wù)對(duì)象隨機(jī)產(chǎn)生一個(gè)唯一的ID值作為文件ID(fd)，還會(huì)計(jì)算生成文件的MD5值，并保存了上傳文件的相關(guān)信息和上傳信息。添加上傳任務(wù)隊(duì)列完成后即可進(jìn)行上傳，由于添加文件的MD5計(jì)算是異步的，所以在上傳時(shí)有些比較大的文件有可能還沒(méi)有獲得MD5值，這時(shí)上傳服務(wù)組件會(huì)自動(dòng)獲取已經(jīng)數(shù)據(jù)準(zhǔn)備完成得上傳任務(wù)，然后依次執(zhí)行。
[0013]下載、刪除的組件服務(wù)和上傳的組件服務(wù)實(shí)現(xiàn)思路是一致的。文件以分片的方式進(jìn)行上傳，文件塊被分散保存在LXPFS集群的Tasknode上。Tasknode的任務(wù)進(jìn)程實(shí)例在接收下載請(qǐng)求時(shí)，會(huì)根據(jù)文件共享池里的映射關(guān)系表索引文件塊，并把這些文件塊拼接形成一個(gè)完整的文件以支持組件下載。
[0014]1.1文件分片
[0015]Http發(fā)送上傳請(qǐng)求，大文件內(nèi)容較多需要傳輸?shù)臄?shù)據(jù)量較大，因此上傳需要很長(zhǎng)時(shí)間。Http的長(zhǎng)時(shí)間請(qǐng)求，占用資源，會(huì)致使瀏覽器掛死。為了防止瀏覽器掛死，所以很多瀏覽器一般都會(huì)限制上傳文件的大小。上傳的文件超過(guò)瀏覽器的文件大小限制，那么就無(wú)法上傳。我們采用的方法是把大文件分割成多個(gè)較小的文件塊，上傳這些文件塊時(shí)間較短，不會(huì)長(zhǎng)時(shí)間占用資源。
[0016]數(shù)據(jù)的最小單位是位，單位的有序數(shù)據(jù)集合組成數(shù)據(jù)塊。而這些數(shù)據(jù)塊的位置是被編號(hào)的，因此，可以認(rèn)為有效的數(shù)據(jù)是有序的，數(shù)據(jù)塊只是數(shù)據(jù)集合的一個(gè)子集，也就是一個(gè)片段。
[0017]文件其實(shí)可以看作是一個(gè)有序的字節(jié)串，字節(jié)串中第一個(gè)字節(jié)是文件的頭，最后一個(gè)字節(jié)是文件的尾。每一個(gè)文件為了便于系統(tǒng)和用戶識(shí)別，都被分配了一個(gè)便于理解的名字。典型的文件操作有讀、寫、創(chuàng)建和刪除等。文件通過(guò)目錄組織起來(lái)，因?yàn)槟夸浺部梢园幽夸洠阅夸浛梢詫訉忧短?，形成文件路徑。從本質(zhì)上講，文件系統(tǒng)是特殊的數(shù)據(jù)分層存儲(chǔ)結(jié)構(gòu)，而文件則是有效存儲(chǔ)的數(shù)據(jù)塊。因此大文件只是一個(gè)較大的有序的數(shù)據(jù)片段，同樣也可以看作是由其他多個(gè)數(shù)據(jù)小片段組成的。當(dāng)然這些數(shù)據(jù)片段并不是隨意組合的，它們是有序的。
[0018]Html5增加了很多新的特性，其中之一就是提供了 Web應(yīng)用可讀取本地文件的API。在此之前讀取本地文件的操作被認(rèn)為是不安全的，所以是被禁止的。使用該特性，按照一個(gè)設(shè)定的大小值來(lái)讀取文件，可以把大文件進(jìn)行分片。每讀取到的一個(gè)文件片段將被封裝成一個(gè)blob對(duì)象，即成為一個(gè)文件塊，也可以說(shuō)是文件切片。根據(jù)文件的大小和分片的設(shè)定值，一個(gè)文件可能被分割成一個(gè)或者多個(gè)文件塊。假設(shè)文件的大小為10M，我們的文件切片的設(shè)定值是4M，那么文件分割后的文件塊數(shù)計(jì)算如下:10M/4M=2.5，所以文件塊數(shù)為3。
[0019]分割后的文件塊，由一個(gè)UUID值標(biāo)識(shí)，這個(gè)值我們可以稱之為文件塊ID。除此之外文件被順序讀取，有序分割，分割后的這些文件塊是有序的，為了標(biāo)明這種有序性，我們使用一個(gè)編號(hào)值來(lái)設(shè)定文件塊的順序。文件分片具體可以參考圖1。
[0020]如圖1所示，大文件被分割成一組文件塊。這時(shí)上傳一個(gè)大文件，需要把它所有的文件切片都進(jìn)行上傳。相當(dāng)于一個(gè)大文件的上傳操作被分解成了一組小文件上傳的操作。
[0021]1.2斷點(diǎn)續(xù)傳
[0022]所謂斷點(diǎn)續(xù)傳，就是網(wǎng)絡(luò)中斷、上傳錯(cuò)誤等原因?qū)е挛募蟼饕馔庵袛?，文件再次上傳時(shí)，不需要從文件的文件頭開始進(jìn)行上傳，而是從文件上傳中斷時(shí)的斷點(diǎn)位置開始上傳的操作。
[0023]現(xiàn)實(shí)生活中，意外是無(wú)法避免的。有時(shí)文件很大，也許有幾G，而帶寬有限，用戶上傳下載文件需要?dú)v時(shí)很久，甚至數(shù)小時(shí)。萬(wàn)一網(wǎng)路中斷，或者出現(xiàn)上傳錯(cuò)誤，不具備斷點(diǎn)續(xù)傳，那該文件又要重新開始上傳或下載，可以想象用戶會(huì)是什么樣的表情。斷點(diǎn)續(xù)傳允許用戶在斷點(diǎn)繼續(xù)上傳，不必從頭開始，它對(duì)于用戶體驗(yàn)是一個(gè)很大的提升。
[0024]文件分片上傳，文件塊的相關(guān)屬性也會(huì)一并傳輸給服務(wù)器。服務(wù)器保存文件的上傳信息，包括文件分片的信息。服務(wù)器通過(guò)這些信息，可以獲取到文件切片數(shù)、已經(jīng)上傳的文件塊，以及文件塊的對(duì)應(yīng)序號(hào)等。當(dāng)意外原因?qū)е律蟼魅蝿?wù)失敗，再次手動(dòng)重啟這次任務(wù)時(shí)，服務(wù)器就會(huì)根據(jù)上次上傳的記錄信息，通過(guò)一定算法獲得當(dāng)前需要上傳的文件切片。也就是說(shuō)，當(dāng)用戶進(jìn)行上傳時(shí)，文件需要上傳哪一片哪些片是完全由服務(wù)器計(jì)算得到，前端只是根據(jù)服務(wù)器的計(jì)算值來(lái)執(zhí)行上傳任務(wù)。
[0025]因此，文件上傳意外中斷，服務(wù)器同樣可以計(jì)算得到上次文件上傳任務(wù)已經(jīng)上傳的斷點(diǎn)值，前端則依據(jù)這個(gè)斷點(diǎn)值來(lái)重啟這個(gè)上傳任務(wù)。文件不會(huì)從文件頭開始上傳，而是從斷點(diǎn)處的文件塊開始上傳，這樣就實(shí)現(xiàn)了斷點(diǎn)續(xù)傳的功能。
[0026]1.3秒傳
[0027]秒傳是一種特殊的上傳技術(shù)手段，事實(shí)上并沒(méi)有實(shí)際的數(shù)據(jù)輸出，只是對(duì)上傳的文件完成一個(gè)映射而已。
[0028]隨著時(shí)間軸的推移，上傳到文件存儲(chǔ)服務(wù)器的文件數(shù)量會(huì)逐漸增多。這些保存在文件服務(wù)器上的文件資源對(duì)于上傳是開放的、共享的，所有的文件資源就形成了一個(gè)文件共享池。上傳的文件資源數(shù)量越大，文件共享池越大，相同文件重復(fù)上傳的機(jī)率就會(huì)越大。如果一個(gè)文件已經(jīng)在文件共享池里存在，這個(gè)文件每次重復(fù)上傳都把該文件的內(nèi)容重復(fù)地傳輸給服務(wù)器，并在服務(wù)器上重復(fù)保存相同的副本，那么這樣既浪費(fèi)存儲(chǔ)空間，上傳效率也極低。上傳到文件服務(wù)器的文件的主要用途是，在用戶需要使用時(shí)提供使用，比如查看文件內(nèi)容、下載文件等。眾所周知在電影院看同一部電影，電影院一般會(huì)安排這些人在同一個(gè)包間內(nèi)進(jìn)行統(tǒng)一播放，而不是為每個(gè)人提供一個(gè)顯示器為每個(gè)人單獨(dú)播放，因?yàn)檫@樣既浪費(fèi)資源，又效率極低。因此，我們只會(huì)為同一文件在文件共享池里保存至多一個(gè)副本。在文件重復(fù)上傳時(shí)，就建立一條記錄映射文件共享池里的對(duì)應(yīng)文件，從而避免了上傳時(shí)文件數(shù)據(jù)的重復(fù)傳輸。
[0029]MD5是一個(gè)將任意長(zhǎng)度的數(shù)據(jù)字符串轉(zhuǎn)化成短的固定長(zhǎng)度的值得單向操作。因此MD5可以用于校驗(yàn)字符串或者文件，如果文件的MD5不一樣，說(shuō)明文件的內(nèi)容也是不一樣的。就好比每個(gè)人的指紋都是唯一的一樣，文件的MD5值也是唯一的。因此可以在文件上傳時(shí)對(duì)文件的MD5進(jìn)行校驗(yàn)，判斷文件是否已經(jīng)存在于文件服務(wù)器上。當(dāng)檢索到上傳文件的MD5值和文件服務(wù)器上某個(gè)文件的MD5值相同，那么服務(wù)器就會(huì)產(chǎn)生一條新記錄保存文件的相關(guān)信息和文件的存儲(chǔ)位置，然后保存于數(shù)據(jù)庫(kù)中，這樣就完成了文件的映射。如果需要使用這個(gè)文件，就會(huì)根據(jù)記錄里記錄文件的存儲(chǔ)位置的信息讀取出文件數(shù)據(jù)，具體如圖2所示。
[0030]2分布式存儲(chǔ)
[0031]LXPFS是一個(gè)輕量級(jí)的分布式文件存儲(chǔ)系統(tǒng)，它和現(xiàn)有的分布式文件系統(tǒng)有很多共同點(diǎn)。但同時(shí)，它和其他的分布式文件系統(tǒng)的區(qū)別也是很明顯的，實(shí)現(xiàn)方式也是全新的。
[0032]LXPFS采用的是主從模式(control I er/worker)的架構(gòu)。一個(gè)LXPFS集群是由一個(gè)Dispatchnode和一定數(shù)目的Tasknode組成。Dispatchnode是一個(gè)controlIer服務(wù)器，負(fù)責(zé)調(diào)配所有文件的存儲(chǔ)以及處理并轉(zhuǎn)發(fā)客戶端的請(qǐng)求。集群中的Tasknode—般是一個(gè)節(jié)點(diǎn)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)和響應(yīng)客戶端的請(qǐng)求。Dispatchnode和Tasknode被設(shè)計(jì)成可以運(yùn)行在安裝GNU/Linux操作系統(tǒng)(OS)的機(jī)器上。一個(gè)典型的部署場(chǎng)景是一臺(tái)機(jī)器上只運(yùn)行一個(gè)Dispatchnode實(shí)例，而集群中的其他機(jī)器分別運(yùn)行一個(gè)Tasknode實(shí)例。事實(shí)上一臺(tái)機(jī)器上可以同時(shí)運(yùn)行多個(gè)實(shí)例進(jìn)程。集群中只有一個(gè)controller服務(wù)器，只有單一的Dispatchnode實(shí)例。我們的controlIer服務(wù)器和worker服務(wù)器是可以相互轉(zhuǎn)換角色的，不過(guò)在轉(zhuǎn)換的過(guò)程中需要做一些特殊的配置和部署。
[0033]如圖3所示，LXPFS使用HA(HighAvailable)高可用集群架構(gòu)。為保證系統(tǒng)運(yùn)行的連續(xù)性，一般有一個(gè)或兩個(gè)以上的節(jié)點(diǎn)，且分為活動(dòng)節(jié)點(diǎn)和備用節(jié)點(diǎn)。當(dāng)活動(dòng)節(jié)點(diǎn)出現(xiàn)問(wèn)題，導(dǎo)致正在運(yùn)行的業(yè)務(wù)(任務(wù))不能正常運(yùn)行時(shí)，備用節(jié)點(diǎn)此時(shí)就會(huì)偵測(cè)到，并立即接續(xù)活動(dòng)節(jié)點(diǎn)來(lái)執(zhí)行業(yè)務(wù)。從而實(shí)現(xiàn)業(yè)務(wù)的不中斷或短暫中斷。圖中worker就是Tasknode的活動(dòng)節(jié)點(diǎn)，而backuper則是Tasknode的備用節(jié)點(diǎn)。controlIer也有一個(gè)備用節(jié)點(diǎn)controlIerI，如果maser發(fā)生意外，control Ier I將取代control Ier進(jìn)行工作。
[0034]2.1文件組織和文件存儲(chǔ)
[0035]2.1.1文件存儲(chǔ)
[0036]LXPFS文件存儲(chǔ)系統(tǒng)將每個(gè)寫入的文件存儲(chǔ)成一系列的數(shù)據(jù)塊，除了最后一個(gè)，所有的數(shù)據(jù)塊都是同樣大小的。每個(gè)文件的數(shù)據(jù)塊大小都是可配置的，并且擁有在集群里唯一的編號(hào)(Block ID),Block ID在前端文件分片時(shí)生成。在Tasknode上，LXPFS基于Linux以文件和目錄的形式組織這些文件數(shù)據(jù)。LXPFS根據(jù)系統(tǒng)時(shí)間，新建一些掛載目錄，文件寫入時(shí)文件塊會(huì)以文件的形式被組織放在相應(yīng)的目錄下。
[0037]如圖4所示，LXPFS集群Tasknodes上所有的文件數(shù)據(jù)形成一個(gè)大的文件存儲(chǔ)空間，在這個(gè)空間里包含了所有接入的Web應(yīng)用的數(shù)據(jù)。在這個(gè)大的存儲(chǔ)空間里有一個(gè)文件共享池，文件共享池里的每個(gè)文件由一個(gè)唯一的MD5與之--對(duì)應(yīng)，這些文件是不同的。接入的應(yīng)用服務(wù)系統(tǒng)在存儲(chǔ)空間里維護(hù)著各自的應(yīng)用空間表，在這張表里每個(gè)文件被賦予一個(gè)文件ID，文件與文件共享池里的文件建立映射，從而實(shí)現(xiàn)了應(yīng)用空間的文件維護(hù)。
[0038]LXPFS支持文件的“一次寫入多次讀取”，就是文件一旦寫入LXPFS集群，該文件的相關(guān)信息就不會(huì)被改動(dòng)，比如文件ID，文件關(guān)聯(lián)的文件塊的存儲(chǔ)信息，以及文件塊的命名等都不會(huì)能被改動(dòng)。這么做是為了維護(hù)文件的完好性。
[0039]LXPFS為了支持高可用性，采用特別的文件存儲(chǔ)策略，具體如下:一個(gè)文件的所屬文件塊被分散在集群中的Tasknode ;—個(gè)文件一定存在多個(gè)備份，并且這些文件備份也以文件塊的方式分散存儲(chǔ)在集群的Tasknode上；這些備份的存儲(chǔ)算法如下:保證任意一個(gè)Tasknode上的所有文件數(shù)據(jù)，在其他Tasknode上至少存在一個(gè)這些文件的完整完好備份。
[0040]為了保障數(shù)據(jù)的有效性，LXPFS會(huì)對(duì)文件塊進(jìn)行有效性檢查。每個(gè)文件塊在寫入前，系統(tǒng)都會(huì)記錄這個(gè)文件塊的MD5值，作為它的有效性檢查的依據(jù)。如果保存在系統(tǒng)上的某個(gè)文件塊計(jì)算得到的MD5值與記錄的MD5值無(wú)法對(duì)應(yīng)，那么說(shuō)明此文件塊內(nèi)容被修改，其將被視為無(wú)效。
[0041]2.1.2文件的刪除
[0042]當(dāng)用戶或應(yīng)用程序刪除某個(gè)文件時(shí)，這個(gè)文件并不是直接從LXPFS上刪除。實(shí)際上LXPFS會(huì)先檢測(cè)這個(gè)文件在共享池里是否還在其他的映射。如果存在即被判斷為軟刪除，那么只是刪除用戶所屬的那條記錄和映射。要是文件不存在其他的映射，就是硬刪除。硬刪除在刪除映射的同時(shí)還會(huì)刪除文件對(duì)應(yīng)的文件塊數(shù)據(jù)。
[0043]2.1.3文件組織
[0044]允許接入的Web應(yīng)用服務(wù)器，它對(duì)于每個(gè)文件都會(huì)附于一個(gè)特殊的組織方式，這個(gè)組織方式我們可以看作是文件的組織路徑。這個(gè)文件的組織路徑和文件的實(shí)際路徑是無(wú)關(guān)的，文件的實(shí)際路徑是文件在LXPFS系統(tǒng)中的實(shí)際保存的路徑。而文件的組織路徑是文件在Web服務(wù)系統(tǒng)中展示的位置，這個(gè)展示的位置有可能是某個(gè)模塊的附件，也有可能就是某個(gè)顯示的目錄。在每次寫入數(shù)據(jù)也就是上傳文件的時(shí)候，上傳請(qǐng)求包含文件在Web應(yīng)用系統(tǒng)的組織路徑，這個(gè)路徑是以字符串的方式保存的。如果Web應(yīng)用系統(tǒng)允許讓LXPFS文件系統(tǒng)查看和運(yùn)維，那么就會(huì)傳入上傳文件的組織路徑。如果Web應(yīng)用系統(tǒng)想要向LXPFS文件系統(tǒng)隱藏文件的組織路徑，可以自己維護(hù)一張組織路徑和路徑ID的映射表，而只傳入文件的路徑ID即可。
[0045]LXPFS基于路徑ID提供了一個(gè)文件版本的功能，如果寫入的文件與應(yīng)用系統(tǒng)已保存的文件的路徑ID相同，并且文件名也相同，就判定為存在文件版本問(wèn)題。每個(gè)文件版本被賦予一個(gè)文件版本序號(hào)。
[0046]2.2Tasknode
[0047]Tasknode節(jié)點(diǎn)主要是用于處理數(shù)據(jù)的存儲(chǔ)，以及管理數(shù)據(jù)存儲(chǔ)的信息。這部分功能被設(shè)計(jì)成一個(gè)進(jìn)程，可以這么說(shuō)一個(gè)實(shí)例進(jìn)程即實(shí)現(xiàn)一個(gè)Tasknode的全部功能。盡管如此一臺(tái)運(yùn)行Linux系統(tǒng)的機(jī)器Tasknode可以同時(shí)運(yùn)行多個(gè)實(shí)例進(jìn)程，最簡(jiǎn)易的部署時(shí)一臺(tái)機(jī)器上運(yùn)行一個(gè)實(shí)例進(jìn)程。為了滿足高并發(fā)，每個(gè)實(shí)例進(jìn)程維護(hù)著一個(gè)可配置線程數(shù)量的線程池和一個(gè)動(dòng)態(tài)擴(kuò)展的任務(wù)隊(duì)列。在這些線程中有一個(gè)比較特殊，它專門接收任務(wù)，然后把接收的任務(wù)放在實(shí)例進(jìn)程的任務(wù)隊(duì)列里等待被線程池里的其他線程處理。任務(wù)隊(duì)列是共享的，因此線程之間對(duì)資源有競(jìng)爭(zhēng)，我們使用了Linux的線程同步方法，所以這些線程是線程安全的。我們采用生產(chǎn)者和消費(fèi)者的模式來(lái)處理任務(wù)，這個(gè)專門接收任務(wù)的線程就是我們的生產(chǎn)者，其他線程取任務(wù)則是消費(fèi)者。消費(fèi)者線程在任務(wù)隊(duì)列為空時(shí)閑置等待，當(dāng)生產(chǎn)者線將得任務(wù)放入任務(wù)隊(duì)列，進(jìn)程就安排線程池里的閑置線程取任務(wù)進(jìn)行處理。當(dāng)線程池里的線程都處于滿負(fù)荷運(yùn)行，任務(wù)就會(huì)在任務(wù)隊(duì)列里，等待消費(fèi)者線程處理。總之，只要任務(wù)隊(duì)列不為空，進(jìn)程都為安排消費(fèi)者線程來(lái)進(jìn)行處理，具體可參考圖5。
[0048]高并發(fā)性還并不只是使用多線程多任務(wù)實(shí)現(xiàn)的，還可以根據(jù)需要?jiǎng)討B(tài)地?cái)U(kuò)展多實(shí)例進(jìn)程處理，正如之前我們所說(shuō)，可以在機(jī)器上運(yùn)行多個(gè)實(shí)例進(jìn)程。為了避免網(wǎng)絡(luò)數(shù)據(jù)阻塞，我們還使用了事件輪詢接口，當(dāng)然我們的網(wǎng)絡(luò)數(shù)據(jù)基本都是及時(shí)通訊的，很少出現(xiàn)阻塞的情況。
[0049]在一臺(tái)機(jī)器上運(yùn)行多個(gè)實(shí)例進(jìn)程，一方面可以處理高并發(fā)，另一方面也可以實(shí)現(xiàn)高可用性。當(dāng)一個(gè)實(shí)例進(jìn)程因?yàn)橐馔饣蛘呶粗e(cuò)誤掛死時(shí)，服務(wù)器依然能夠正常地處理數(shù)據(jù)存儲(chǔ)的請(qǐng)求。當(dāng)然我們后續(xù)還會(huì)加入很多容錯(cuò)機(jī)制，如果可能我們還將實(shí)現(xiàn)實(shí)例進(jìn)程掛死現(xiàn)場(chǎng)保護(hù)機(jī)制，即在實(shí)例進(jìn)程掛死后，它的任務(wù)隊(duì)列可以被保護(hù)起來(lái)，然后讓其他的實(shí)例進(jìn)程繼續(xù)進(jìn)行處理。
[0050]除此之外，我們也在每個(gè)服務(wù)器上部署實(shí)現(xiàn)了一個(gè)后臺(tái)運(yùn)行的維護(hù)進(jìn)程。它的工作主要是維護(hù)機(jī)器上多個(gè)實(shí)例進(jìn)程的正常運(yùn)行，Linux系統(tǒng)不能隨意關(guān)閉這些實(shí)例進(jìn)程。Linux中每個(gè)進(jìn)程都對(duì)應(yīng)一個(gè)唯一的pid，實(shí)例進(jìn)程掛死時(shí)，維護(hù)進(jìn)程就會(huì)收到一個(gè)消息，通過(guò)消息可以獲得掛死的進(jìn)程的pid，然后維護(hù)進(jìn)程再使用進(jìn)程表里的進(jìn)程參數(shù)啟動(dòng)該實(shí)例進(jìn)程。因此即使這些實(shí)例進(jìn)程被意外關(guān)閉，或者因?yàn)槲粗e(cuò)誤意外掛死，它們依然能夠被維護(hù)進(jìn)程自啟動(dòng)。
[0051]2.3Dispatchnode
[0052]Dispatchnode主要是分發(fā)存儲(chǔ)數(shù)據(jù)和調(diào)度任務(wù)，這種分發(fā)和調(diào)度是基于一定的綜合考量，目的是為了更高效、更合理的存儲(chǔ)數(shù)據(jù)和執(zhí)行任務(wù)。
[0053]Dispatchnode維護(hù)著多張數(shù)據(jù)參數(shù)表，根據(jù)這些參數(shù)表，Dispatchnode的實(shí)例進(jìn)程獲取參數(shù)，然后應(yīng)用于負(fù)載均衡的算法。應(yīng)用的每個(gè)訪問(wèn)請(qǐng)求，都會(huì)經(jīng)過(guò)Dispatchnode。Dispatchnode在接收到請(qǐng)求信息后，會(huì)解析請(qǐng)求數(shù)據(jù)，根據(jù)請(qǐng)求數(shù)據(jù)進(jìn)行負(fù)載均衡計(jì)算，最后有效地派發(fā)任務(wù)給Tasknode，如圖6所示。
[0054]Dispatchnode的工作內(nèi)容可以抽象為以下幾個(gè)部分:
[0055]a.驗(yàn)證訪問(wèn)請(qǐng)求的IP是否已經(jīng)注冊(cè)；
[0056]b.解析訪問(wèn)請(qǐng)求數(shù)據(jù)包，獲取訪問(wèn)操作方式、操作對(duì)象以及其他相關(guān)信息；
[0057]c.利用心跳機(jī)制，獲取集群中目標(biāo)節(jié)點(diǎn)服務(wù)器的負(fù)載參數(shù)，計(jì)算分析這些參數(shù)，獲取最適合委派任務(wù)的目標(biāo)節(jié)點(diǎn)位置；
[0058]d.使用操作對(duì)象文件的MD5值索引文件，找到文件所在目標(biāo)節(jié)點(diǎn)服務(wù)器實(shí)現(xiàn)秒傳，否則將任務(wù)派發(fā)給最適合的目標(biāo)節(jié)點(diǎn)。
[0059]2.4心跳機(jī)制
[0060]集群的服務(wù)器之間是通過(guò)網(wǎng)絡(luò)來(lái)相互溝通的，controller服務(wù)器管理著其他所有的worker服務(wù)器。因此Dispatchnode會(huì)定時(shí)地例行檢測(cè)Tasknode是否運(yùn)行正常以及運(yùn)行情況。每個(gè)Tasknode節(jié)點(diǎn)周期性地向Dispatchnode發(fā)送心跳信號(hào)，心跳信號(hào)里包含有一些用于負(fù)載均衡策略的重要參數(shù)值。Dispatchnode也可以主動(dòng)向Tasknode發(fā)送一個(gè)檢測(cè)信號(hào)。Tasknode收到這個(gè)信號(hào)就會(huì)收集自己的運(yùn)行情況，統(tǒng)計(jì)匯總?cè)蝿?wù)隊(duì)列的任務(wù)量、CPU和內(nèi)存等服務(wù)器的負(fù)載參數(shù)，然后發(fā)送給Dispatchnode dispatchnode在獲取這些數(shù)據(jù)后，會(huì)先保存再做統(tǒng)計(jì)分析，最后應(yīng)用于負(fù)載均衡策略。事實(shí)上網(wǎng)路中斷、worker服務(wù)器意外掛死等因素都會(huì)導(dǎo)致某一部分Tasknode跟Dispatchnode斷聯(lián)，Dispatchnode通過(guò)心跳機(jī)制來(lái)判斷這一情況。對(duì)無(wú)法接收到心跳信號(hào)的Tasknode ,Dispatchnode會(huì)將其標(biāo)記為宕機(jī)狀態(tài)，不會(huì)再將新的工作任務(wù)派發(fā)給它們。此時(shí)存儲(chǔ)于判定為宕機(jī)的Tasknode上的所有數(shù)據(jù)將失效，但是LXPFS集群使用一系列的高可用性措施，保證了即使出現(xiàn)部分Tasknode宕機(jī)，系統(tǒng)的數(shù)據(jù)依然能夠完備，系統(tǒng)依然運(yùn)行正常，具體參考數(shù)據(jù)安全和文件存儲(chǔ)小節(jié)。
[0061 ] 2.5負(fù)載均衡
[0062]在對(duì)Tasknode進(jìn)行部署的時(shí)候，一般都會(huì)配置它的警戒線和臨界點(diǎn)。LXPFS集群中所有的數(shù)據(jù)都保存在這些Tasknode上，如何合理保存這些文件數(shù)據(jù)?我們的原則是盡量使集群中每個(gè)Tasknode的負(fù)荷趨于平等。在LXPFS系統(tǒng)運(yùn)行開始時(shí)，Dispatchnode記錄每個(gè)Tasknode的警戒線和臨界點(diǎn)，即使后來(lái)某個(gè)Tasknode的這些參數(shù)值改變，Dispatchnode也可以通過(guò)心跳機(jī)制獲取得到。Dispatchnode是起到一個(gè)調(diào)度任務(wù)的作用，所以負(fù)載均衡在此處實(shí)現(xiàn)。
[0063]如果某些Tasknode節(jié)點(diǎn)上的空閑空間較富余而低于設(shè)定的臨界點(diǎn)，按照負(fù)載均衡策略系統(tǒng)就會(huì)自動(dòng)地將數(shù)據(jù)從集群中儲(chǔ)存空間緊張或者占用較大的Tasknode移動(dòng)到其他空閑的Tasknode。如果某些Tasknode在某個(gè)時(shí)刻任務(wù)隊(duì)列的任務(wù)量較大，內(nèi)存和CPU使用率極高，Dispatchnode在調(diào)度任務(wù)時(shí)會(huì)盡量將任務(wù)派發(fā)給負(fù)荷較小的Tasknode。當(dāng)然Dispatchnode在派發(fā)任務(wù)時(shí)，就會(huì)出于均衡的考慮，盡量把任務(wù)較多地派發(fā)給性能較高負(fù)荷較輕的Tasknode。只是可能某些情況導(dǎo)致Tasknode不能正常進(jìn)行任務(wù)工作，導(dǎo)致任務(wù)隊(duì)列堆積，從而造成負(fù)荷增大，這個(gè)時(shí)候Dispatchnode又會(huì)起到再次均衡的作用。
[0064]實(shí)際運(yùn)行過(guò)程中，這種均衡需要考慮的維度是多維的。可能有些維度還存在著非此即彼的情況，所以在制定負(fù)載均衡策略時(shí)我們會(huì)出于綜合的考慮優(yōu)先選擇某個(gè)維度，不過(guò)我們保持集群中所有Tasknode的盡量均衡的原則是不變的。
[0065]2.6安全
[0066]在保障LXPFS系統(tǒng)正常運(yùn)行的同時(shí)，其安全也是十分重要的?；诎踩袃煞矫娴目紤]，一是要保障數(shù)據(jù)不外泄，二是數(shù)據(jù)的完好性。
[0067]2.6.1網(wǎng)絡(luò)安全
[0068]LXPFS系統(tǒng)設(shè)計(jì)的主要目的就為了降低多個(gè)Web應(yīng)用服務(wù)系統(tǒng)的文件管理模塊的開發(fā)難度和減小其開發(fā)周期，并且統(tǒng)一它們的文件管理功能，使之便于維護(hù)。LXPFS系統(tǒng)允許多個(gè)Web應(yīng)用服務(wù)系統(tǒng)接入，在接入之前我們希望每個(gè)Web應(yīng)用服務(wù)系統(tǒng)首先完成注冊(cè)。每個(gè)Web應(yīng)用服務(wù)器一旦開啟就不會(huì)關(guān)閉，而它們的IP和網(wǎng)卡的物理地址是固定的。在它們接入LXPFS系統(tǒng)之前，需要先提供Web應(yīng)用服務(wù)系統(tǒng)所部署的服務(wù)器的IP以及網(wǎng)卡的物理地址等信息，由LXPFS系統(tǒng)管理人員根據(jù)這些信息完成系統(tǒng)接入的注冊(cè)工作。一旦注冊(cè)，我們則認(rèn)為來(lái)此這臺(tái)機(jī)器的數(shù)據(jù)是安全的，是網(wǎng)絡(luò)安全的，允許接入并為之提供服務(wù)。否則，則認(rèn)為是不安全，不給于提供服務(wù)。數(shù)據(jù)訪問(wèn)時(shí)，應(yīng)用需要發(fā)送訪問(wèn)請(qǐng)求給Dispatchnode，也就是control Ier服務(wù)器。在Dispatchnode會(huì)攔截訪問(wèn)請(qǐng)求并驗(yàn)證請(qǐng)求的來(lái)源，如果來(lái)源安全，則允許訪問(wèn)，否則拒絕訪問(wèn)。
[0069]其次，LXPFS文件存儲(chǔ)系統(tǒng)對(duì)于文件不做任何的權(quán)限控制，所有的對(duì)于文件訪問(wèn)的權(quán)限控制都交還接入的Web應(yīng)用服務(wù)系統(tǒng)。LXPFS只對(duì)接入的Web應(yīng)用服務(wù)系統(tǒng)提供數(shù)據(jù)的寫入、讀取和刪除的服務(wù)，至于這些文件能被Web應(yīng)用服務(wù)系統(tǒng)中的哪些用戶所使用和訪問(wèn)，完全是由它們進(jìn)行權(quán)限控制處理的。最后在數(shù)據(jù)存儲(chǔ)一節(jié)中，我們知道，LXPFS對(duì)每個(gè)接入的系統(tǒng)的數(shù)據(jù)都做了隔離。
[0070]2.7動(dòng)態(tài)擴(kuò)展 worker
[0071]原有的LXPFS集群運(yùn)行一定時(shí)間后，隨著存儲(chǔ)的文件越來(lái)越多，集群容量出現(xiàn)不足，此時(shí)需要對(duì)LXPFS集群擴(kuò)容?；蛘呤褂玫娜嗽絹?lái)越多，對(duì)LXPFS集群的并發(fā)性有更高的要求，這就亟待需要對(duì)LXPFS集群進(jìn)行擴(kuò)展。由于worker與control Ier之間使用心跳機(jī)制通信，如果系統(tǒng)擴(kuò)展，只需要將相應(yīng)數(shù)量的worker服務(wù)器部署好應(yīng)用程序啟動(dòng)即可。這些worker服務(wù)器會(huì)向control Ier進(jìn)行心跳匯報(bào)。control Ier接收到這些新worker服務(wù)器的心跳匯報(bào)，會(huì)自動(dòng)完成worker在LXPFS系統(tǒng)中注冊(cè)工作。注冊(cè)完成后，LXPFS集群就實(shí)現(xiàn)了一次新的擴(kuò)展，不需要重啟系統(tǒng)就實(shí)現(xiàn)擴(kuò)展的方式就是動(dòng)態(tài)擴(kuò)展。對(duì)于擴(kuò)展新加入的worker服務(wù)器，將從多方面極大地減少LXPFS集群的負(fù)荷。新worker服務(wù)器其存儲(chǔ)空間會(huì)相比其他的worker服務(wù)器要富余很多，此時(shí)LXPFS系統(tǒng)會(huì)根據(jù)動(dòng)態(tài)負(fù)載均衡的策略，來(lái)將存儲(chǔ)空間比較緊張的worker服務(wù)器的數(shù)據(jù)向這些新加入的worker服務(wù)器移動(dòng)。為了避免數(shù)據(jù)轉(zhuǎn)移在LXPFS集群負(fù)載大的時(shí)段進(jìn)行，我們一般可以制定工作計(jì)劃在某個(gè)時(shí)段來(lái)移動(dòng)數(shù)據(jù)。
[0072]本發(fā)明是通過(guò)如下技術(shù)方案來(lái)實(shí)現(xiàn)的:
[0073]LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，本發(fā)明特征在于，采用LXPFS集群給應(yīng)用提供訪問(wèn)方法，通過(guò)封裝好的JS API訪問(wèn)LXPFS中的文件;訪問(wèn)LXPFS文件的方式分為三種:讀、寫和刪除；在前端實(shí)現(xiàn)了訪問(wèn)LXPFS文件的組件，在Web應(yīng)用開發(fā)中，只需要生成一個(gè)組件，調(diào)用相應(yīng)的接口就能實(shí)現(xiàn)訪問(wèn)；系統(tǒng)采用主從模式的架構(gòu)，由一個(gè)Dispatchnode和一個(gè)及以上的Tasknode組成;Dispatchnode是一個(gè)controller服務(wù)器，負(fù)責(zé)調(diào)配所有文件的存儲(chǔ)以及處理并轉(zhuǎn)發(fā)客戶端的請(qǐng)求，Tasknode是在每節(jié)點(diǎn)設(shè)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)和響應(yīng)客戶端的請(qǐng)求;上傳文件是將數(shù)據(jù)寫入LXPFS集群的Tasknode中，下載文件則是讀取Tasknode文件數(shù)據(jù)。
[0074]Dispatchnode的工作內(nèi)容分為以下幾個(gè)部分:
[0075]a.驗(yàn)證訪問(wèn)請(qǐng)求的IP是否已經(jīng)注冊(cè)；
[0076]b.解析訪問(wèn)請(qǐng)求數(shù)據(jù)包，獲取訪問(wèn)操作方式、操作對(duì)象以及其他相關(guān)信息；
[0077]c.利用心跳機(jī)制，獲取集群中目標(biāo)節(jié)點(diǎn)服務(wù)器的負(fù)載參數(shù)，計(jì)算分析這些參數(shù)，獲取最適合委派任務(wù)的目標(biāo)節(jié)點(diǎn)位置；
[0078]d.使用操作對(duì)象文件的MD5值索引文件，找到文件所在目標(biāo)節(jié)點(diǎn)服務(wù)器實(shí)現(xiàn)秒傳，否則將任務(wù)派發(fā)給最適合的目標(biāo)節(jié)點(diǎn)。
[0079]每個(gè)文件塊在寫入前，系統(tǒng)都會(huì)記錄這個(gè)文件塊的MD5值，作為它的有效性檢查的依據(jù)；如果保存在系統(tǒng)上的某個(gè)文件塊計(jì)算得到的MD5值與記錄的MD5值無(wú)法對(duì)應(yīng)，那么說(shuō)明此文件塊內(nèi)容被修改，其將被視為無(wú)效。
[0080]在系統(tǒng)運(yùn)行開始時(shí)，Dispatchnode記錄每個(gè)Tasknode的警戒線和臨界點(diǎn)，即使后來(lái)某個(gè)Tasknode的這些參數(shù)值改變，Dispatchnode也可以通過(guò)心跳機(jī)制獲取得到。
[0081 ] 上傳模塊服務(wù)被封裝成一個(gè)實(shí)體類QFileUpload，每個(gè)QFileUpload實(shí)體類中維護(hù)著一個(gè)上傳隊(duì)列，上傳之前需要先選擇本地文件，選擇的一個(gè)本地文件將被封裝成一個(gè)上傳任務(wù)對(duì)象，并被自動(dòng)添加到上傳任務(wù)隊(duì)列里;上傳任務(wù)對(duì)象隨機(jī)產(chǎn)生一個(gè)唯一的ID值作為文件ID，還會(huì)計(jì)算生成文件的MD5值，并保存了上傳文件的相關(guān)信息和上傳信息；添加上傳任務(wù)隊(duì)列完成后即可進(jìn)行上傳，由于添加文件的MD5計(jì)算是異步的，所以在上傳時(shí)有些比較大的文件有可能還沒(méi)有獲得MD5值，這時(shí)上傳服務(wù)組件會(huì)自動(dòng)獲取已經(jīng)數(shù)據(jù)準(zhǔn)備完成得上傳任務(wù)，然后依次執(zhí)行。
[0082]下載、刪除模塊服務(wù)和上傳模塊服務(wù)的實(shí)現(xiàn)思路是一致的，文件以分片的方式進(jìn)行上傳，分割后的文件塊被分散保存在LXPFS集群的Tasknode上;Tasknode的任務(wù)進(jìn)程實(shí)例在接收下載請(qǐng)求時(shí)，會(huì)根據(jù)文件共享池里的映射關(guān)系表索引文件塊，并把這些文件塊拼接形成一個(gè)完整的文件以支持組件下載。
[0083]當(dāng)用戶或應(yīng)用程序刪除某個(gè)文件時(shí)，LXPFS集群會(huì)先檢測(cè)這個(gè)文件在共享池里是否還在其他的映射;如果存在即被判斷為軟刪除，那么只是刪除用戶所屬的那條記錄和映射;要是文件不存在其他的映射，就是硬刪除，硬刪除在刪除映射的同時(shí)還會(huì)刪除文件對(duì)應(yīng)的文件塊數(shù)據(jù)。
[0084]本發(fā)明中，Tasknode分為活動(dòng)節(jié)點(diǎn)和備用節(jié)點(diǎn)，controller服務(wù)器也分為活動(dòng)節(jié)點(diǎn)和備用節(jié)點(diǎn)。
[0085]本發(fā)明中，文件以分片的方式進(jìn)行上傳后，分割后的文件塊由一個(gè)UUID值標(biāo)識(shí)，這個(gè)值即為文件塊的ID，且分割后的文件塊是有序的。
[0086]本發(fā)明中，當(dāng)網(wǎng)絡(luò)中斷或上傳錯(cuò)的原因?qū)е挛募蟼饕馔庵袛鄷r(shí)會(huì)斷點(diǎn)續(xù)傳，SP文件再次上傳不需要從文件的文件頭開始進(jìn)行上傳，而是從文件上傳中斷時(shí)的斷點(diǎn)位置開始上傳。
[0087]本發(fā)明中，controller服務(wù)器和Tasknode能相互轉(zhuǎn)換。
[0088]本發(fā)明所述心跳機(jī)制是指:每個(gè)Tasknode周期性地向Dispatchnode發(fā)送心跳信號(hào)，心跳信號(hào)里包含有一些用于負(fù)載均衡策略的參數(shù)值；Dispatchnode也可以主動(dòng)向Tasknode發(fā)送一個(gè)檢測(cè)信號(hào)，Tasknode收到這個(gè)信號(hào)就會(huì)收集自己的運(yùn)行情況，統(tǒng)計(jì)匯總?cè)蝿?wù)隊(duì)列的任務(wù)量、CPU和內(nèi)存等服務(wù)器的負(fù)載參數(shù)，然后發(fā)送給Di spatchnode，Dispatchnode在獲取這些數(shù)據(jù)后，會(huì)先保存再做統(tǒng)計(jì)分析，最后應(yīng)用于負(fù)載均衡策略。
[0089]如果Tasknode節(jié)點(diǎn)上的空閑空間較富余而低于設(shè)定的臨界點(diǎn)，按照負(fù)載均衡策略系統(tǒng)就會(huì)自動(dòng)地將數(shù)據(jù)從集群中儲(chǔ)存空間緊張或者占用較大的Tasknode移動(dòng)到其他空閑的Tasknode ;如果Tasknode在某個(gè)時(shí)刻任務(wù)隊(duì)列的任務(wù)量較大，內(nèi)存和CHJ使用率極高，Dispatchnode在調(diào)度任務(wù)時(shí)會(huì)盡量將任務(wù)派發(fā)給負(fù)荷較小的Tasknode。
[°09°] 數(shù)據(jù)訪問(wèn)時(shí)，應(yīng)用需要發(fā)送訪問(wèn)請(qǐng)求給Dispatchnode，在Dispatchnode會(huì)攔截訪問(wèn)請(qǐng)求并驗(yàn)證請(qǐng)求的來(lái)源，如果來(lái)源安全，則允許訪問(wèn)，否則拒絕訪問(wèn)。
[0091 ] 該系統(tǒng)能進(jìn)行動(dòng)態(tài)擴(kuò)展，具體為:由于Tasknode與controlIer服務(wù)器之間使用心跳機(jī)制通信，系統(tǒng)擴(kuò)展時(shí)只需要將Tasknode下的worker服務(wù)器部署好應(yīng)用程序啟動(dòng)即可；這些worker服務(wù)器會(huì)向control Ier服務(wù)器進(jìn)行心跳匯報(bào);control Ier服務(wù)器接收到這些新worker服務(wù)器的心跳匯報(bào)，會(huì)自動(dòng)完成worker服務(wù)器在系統(tǒng)中的注冊(cè)工作；注冊(cè)完成后，LXPFS集群就實(shí)現(xiàn)了一次新的擴(kuò)展而不需要重啟系統(tǒng)。
[0092]本發(fā)明具有以下有益效果:
[0093]1、LXPFS統(tǒng)一管理多應(yīng)用的文件，擴(kuò)大了文件共享池的范圍，增加了秒傳的機(jī)率，使上傳效率有很大提高，同時(shí)也降低了 Web應(yīng)用中的文件管理的運(yùn)維成本。
[0094]2、支持高可用性，采用特別的文件存儲(chǔ)策略，具體如下:一個(gè)文件的所屬文件塊被分散在集群中的Tasknode ； 一個(gè)文件一定存在多個(gè)備份，并且這些文件備份也以文件塊的方式分散存儲(chǔ)在集群的Tasknode上；這些備份的存儲(chǔ)算法遵從如下規(guī)則:保證任意一個(gè)Tasknode上的所有文件數(shù)據(jù)，在其他Tasknode上至少存在一個(gè)這些文件的完整完好備份。
[0095]3、保障數(shù)據(jù)的有效性:LXPFS會(huì)對(duì)文件塊進(jìn)行有效性檢查。每個(gè)文件塊在寫入前，系統(tǒng)都會(huì)記錄這個(gè)文件塊的MD5值，作為它的有效性檢查的依據(jù)。如果保存在系統(tǒng)上的某個(gè)文件塊計(jì)算得到的MD5值與記錄的MD5值無(wú)法對(duì)應(yīng)，那么說(shuō)明此文件塊內(nèi)容被修改，其將被視為無(wú)效。
[0096]4、斷點(diǎn)續(xù)傳:當(dāng)網(wǎng)絡(luò)中斷、上傳錯(cuò)誤等原因?qū)е挛募蟼饕馔庵袛鄷r(shí)，文件再次上傳不需要從文件的文件頭開始進(jìn)行上傳，而是從文件上傳中斷時(shí)的斷點(diǎn)位置開始上傳的操作。
[0097]5、動(dòng)態(tài)擴(kuò)展worker:由于worker與controlIer之間使用心跳機(jī)制通信，如果系統(tǒng)擴(kuò)展，只需要將相應(yīng)數(shù)量的worker服務(wù)器部署好應(yīng)用程序啟動(dòng)即可。這些worker服務(wù)器會(huì)向control Ier進(jìn)行心跳匯報(bào)。control Ier接收到這些新worker服務(wù)器的心跳匯報(bào)，會(huì)自動(dòng)完成worker在LXPFS系統(tǒng)中注冊(cè)工作。注冊(cè)完成后，LXPFS集群就實(shí)現(xiàn)了一次新的擴(kuò)展。
【附圖說(shuō)明】
[0098]圖1為本發(fā)明中文件分割的示意圖；
[0099]圖2為本發(fā)明中文件實(shí)現(xiàn)秒傳的示意圖；
[0100]圖3為本發(fā)明的架構(gòu)示意圖；
[0101]圖4為本發(fā)明中文件存儲(chǔ)結(jié)構(gòu)示意圖；
[0102]圖5為本發(fā)明實(shí)例進(jìn)程內(nèi)部實(shí)現(xiàn)圖；
[0103]圖6為L(zhǎng)XPFS分布式文件管理系統(tǒng)。
【具體實(shí)施方式】
[0104]見(jiàn)圖1-圖6，LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，本發(fā)明特征在于，采用LXPFS集群給應(yīng)用提供訪問(wèn)方法，通過(guò)封裝好的JS API訪問(wèn)LXPFS中的文件;訪問(wèn)LXPFS文件的方式分為三種:讀、寫和刪除;在前端實(shí)現(xiàn)了訪問(wèn)LXPFS文件的組件，在Web應(yīng)用開發(fā)中，只需要生成一個(gè)組件，調(diào)用相應(yīng)的接口就能實(shí)現(xiàn)訪問(wèn)；系統(tǒng)采用主從模式的架構(gòu)，由一個(gè)Dispatchnode和一個(gè)及以上的Tasknode組成;Di spatchnode是一個(gè)control Ier服務(wù)器，負(fù)責(zé)調(diào)配所有文件的存儲(chǔ)以及處理并轉(zhuǎn)發(fā)客戶端的請(qǐng)求，Tasknode是在每節(jié)點(diǎn)設(shè)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)和響應(yīng)客戶端的請(qǐng)求;上傳文件是將數(shù)據(jù)寫入LXPFS集群的Tasknode中，下載文件則是讀取Tasknode文件數(shù)據(jù)。
[0105]Dispatchnode的工作內(nèi)容分為以下幾個(gè)部分:
[0106]a.驗(yàn)證訪問(wèn)請(qǐng)求的IP是否已經(jīng)注冊(cè)；
[0107]b.解析訪問(wèn)請(qǐng)求數(shù)據(jù)包，獲取訪問(wèn)操作方式、操作對(duì)象以及其他相關(guān)信息；
[0108]c.利用心跳機(jī)制，獲取集群中目標(biāo)節(jié)點(diǎn)服務(wù)器的負(fù)載參數(shù)，計(jì)算分析這些參數(shù)，獲取最適合委派任務(wù)的目標(biāo)節(jié)點(diǎn)位置；
[0109]d.使用操作對(duì)象文件的MD5值索引文件，找到文件所在目標(biāo)節(jié)點(diǎn)服務(wù)器實(shí)現(xiàn)秒傳，否則將任務(wù)派發(fā)給最適合的目標(biāo)節(jié)點(diǎn)。
[0110]每個(gè)文件塊在寫入前，系統(tǒng)都會(huì)記錄這個(gè)文件塊的MD5值，作為它的有效性檢查的依據(jù)；如果保存在系統(tǒng)上的某個(gè)文件塊計(jì)算得到的MD5值與記錄的MD5值無(wú)法對(duì)應(yīng)，那么說(shuō)明此文件塊內(nèi)容被修改，其將被視為無(wú)效。
[O111 ] 在系統(tǒng)運(yùn)行開始時(shí)，Dispatchnode記錄每個(gè)Tasknode的警戒線和臨界點(diǎn)，即使后來(lái)某個(gè)Tasknode的這些參數(shù)值改變，Dispatchnode也可以通過(guò)心跳機(jī)制獲取得到。
[0112]上傳模塊服務(wù)被封裝成一個(gè)實(shí)體類QFileUpload，每個(gè)QFileUpload實(shí)體類中維護(hù)著一個(gè)上傳隊(duì)列，上傳之前需要先選擇本地文件，選擇的一個(gè)本地文件將被封裝成一個(gè)上傳任務(wù)對(duì)象，并被自動(dòng)添加到上傳任務(wù)隊(duì)列里;上傳任務(wù)對(duì)象隨機(jī)產(chǎn)生一個(gè)唯一的ID值作為文件ID，還會(huì)計(jì)算生成文件的MD5值，并保存了上傳文件的相關(guān)信息和上傳信息；添加上傳任務(wù)隊(duì)列完成后即可進(jìn)行上傳，由于添加文件的MD5計(jì)算是異步的，所以在上傳時(shí)有些比較大的文件有可能還沒(méi)有獲得MD5值，這時(shí)上傳服務(wù)組件會(huì)自動(dòng)獲取已經(jīng)數(shù)據(jù)準(zhǔn)備完成得上傳任務(wù)，然后依次執(zhí)行。
[0113]下載、刪除模塊服務(wù)和上傳模塊服務(wù)的實(shí)現(xiàn)思路是一致的，文件以分片的方式進(jìn)行上傳，分割后的文件塊被分散保存在LXPFS集群的Tasknode上;Tasknode的任務(wù)進(jìn)程實(shí)例在接收下載請(qǐng)求時(shí)，會(huì)根據(jù)文件共享池里的映射關(guān)系表索引文件塊，并把這些文件塊拼接形成一個(gè)完整的文件以支持組件下載。
[0114]當(dāng)用戶或應(yīng)用程序刪除某個(gè)文件時(shí)，LXPFS集群會(huì)先檢測(cè)這個(gè)文件在共享池里是否還在其他的映射;如果存在即被判斷為軟刪除，那么只是刪除用戶所屬的那條記錄和映射;要是文件不存在其他的映射，就是硬刪除，硬刪除在刪除映射的同時(shí)還會(huì)刪除文件對(duì)應(yīng)的文件塊數(shù)據(jù)。
[0115]本發(fā)明中，Tasknode分為活動(dòng)節(jié)點(diǎn)和備用節(jié)點(diǎn)，controller服務(wù)器也分為活動(dòng)節(jié)點(diǎn)和備用節(jié)點(diǎn)。
[0116]本發(fā)明中，文件以分片的方式進(jìn)行上傳后，分割后的文件塊由一個(gè)UUID值標(biāo)識(shí)，這個(gè)值即為文件塊的ID，且分割后的文件塊是有序的。
[0117]本發(fā)明中，當(dāng)網(wǎng)絡(luò)中斷或上傳錯(cuò)的原因?qū)е挛募蟼饕馔庵袛鄷r(shí)會(huì)斷點(diǎn)續(xù)傳，SP文件再次上傳不需要從文件的文件頭開始進(jìn)行上傳，而是從文件上傳中斷時(shí)的斷點(diǎn)位置開始上傳。[0?18] 本發(fā)明中，controller服務(wù)器和Tasknode能相互轉(zhuǎn)換。
[0119]本發(fā)明所述心跳機(jī)制是指:每個(gè)Tasknode周期性地向Dispatchnode發(fā)送心跳信號(hào)，心跳信號(hào)里包含有一些用于負(fù)載均衡策略的參數(shù)值；Dispatchnode也可以主動(dòng)向Tasknode發(fā)送一個(gè)檢測(cè)信號(hào)，Tasknode收到這個(gè)信號(hào)就會(huì)收集自己的運(yùn)行情況，統(tǒng)計(jì)匯總?cè)蝿?wù)隊(duì)列的任務(wù)量、CPU和內(nèi)存等服務(wù)器的負(fù)載參數(shù)，然后發(fā)送給Dispatchnode，Dispatchnode在獲取這些數(shù)據(jù)后，會(huì)先保存再做統(tǒng)計(jì)分析，最后應(yīng)用于負(fù)載均衡策略。
[0120]如果Tasknode節(jié)點(diǎn)上的空閑空間較富余而低于設(shè)定的臨界點(diǎn)，按照負(fù)載均衡策略系統(tǒng)就會(huì)自動(dòng)地將數(shù)據(jù)從集群中儲(chǔ)存空間緊張或者占用較大的Tasknode移動(dòng)到其他空閑的Tasknode ;如果Tasknode在某個(gè)時(shí)刻任務(wù)隊(duì)列的任務(wù)量較大，內(nèi)存和CHJ使用率極高，Dispatchnode在調(diào)度任務(wù)時(shí)會(huì)盡量將任務(wù)派發(fā)給負(fù)荷較小的Tasknode。
[°121 ] 數(shù)據(jù)訪問(wèn)時(shí)，應(yīng)用需要發(fā)送訪問(wèn)請(qǐng)求給Dispatchnode，在Dispatchnode會(huì)攔截訪問(wèn)請(qǐng)求并驗(yàn)證請(qǐng)求的來(lái)源，如果來(lái)源安全，則允許訪問(wèn)，否則拒絕訪問(wèn)。
[0122] 該系統(tǒng)能進(jìn)行動(dòng)態(tài)擴(kuò)展，具體為:由于Tasknode與controlIer服務(wù)器之間使用心跳機(jī)制通信，系統(tǒng)擴(kuò)展時(shí)只需要將Tasknode下的worker服務(wù)器部署好應(yīng)用程序啟動(dòng)即可；這些worker服務(wù)器會(huì)向control Ier服務(wù)器進(jìn)行心跳匯報(bào);control Ier服務(wù)器接收到這些新worker服務(wù)器的心跳匯報(bào)，會(huì)自動(dòng)完成worker服務(wù)器在系統(tǒng)中的注冊(cè)工作；注冊(cè)完成后，LXPFS集群就實(shí)現(xiàn)了一次新的擴(kuò)展而不需要重啟系統(tǒng)。
【主權(quán)項(xiàng)】
1.LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于，采用LXPFS集群給應(yīng)用提供訪問(wèn)方法，通過(guò)封裝好的JS API訪問(wèn)LXPFS中的文件;訪問(wèn)LXPFS文件的方式分為三種:讀、寫和刪除；在前端實(shí)現(xiàn)了訪問(wèn)LXPFS文件的組件，在Web應(yīng)用開發(fā)中，只需要生成一個(gè)組件，調(diào)用相應(yīng)的接口就能實(shí)現(xiàn)訪問(wèn)；該系統(tǒng)采用主從模式的架構(gòu)，由一個(gè)Dispatchnode和一個(gè)及以上的Tasknode組成;Dispatchnode是一個(gè)control Ier服務(wù)器，負(fù)責(zé)調(diào)配所有文件的存儲(chǔ)以及處理并轉(zhuǎn)發(fā)客戶端的請(qǐng)求，Tasknode是在每節(jié)點(diǎn)設(shè)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)和響應(yīng)客戶端的請(qǐng)求；上傳文件是將數(shù)據(jù)寫入LXPFS集群的Tasknode中，下載文件則是讀取Tasknode文件數(shù)據(jù)； Dispatchnode的工作內(nèi)容分為以下幾個(gè)部分: a.驗(yàn)證訪問(wèn)請(qǐng)求的IP是否已經(jīng)注冊(cè)； b.解析訪問(wèn)請(qǐng)求數(shù)據(jù)包，獲取訪問(wèn)操作方式、操作對(duì)象以及其他相關(guān)信息； c.利用心跳機(jī)制，獲取集群中目標(biāo)節(jié)點(diǎn)服務(wù)器的負(fù)載參數(shù)，計(jì)算分析這些參數(shù)，獲取最適合委派任務(wù)的目標(biāo)節(jié)點(diǎn)位置； d.使用操作對(duì)象文件的MD5值索引文件，找到文件所在目標(biāo)節(jié)點(diǎn)服務(wù)器實(shí)現(xiàn)秒傳，否則將任務(wù)派發(fā)給最適合的目標(biāo)節(jié)點(diǎn)； 每個(gè)文件塊在寫入前，系統(tǒng)都會(huì)記錄這個(gè)文件塊的MD5值，作為它的有效性檢查的依據(jù)；如果保存在系統(tǒng)上的某個(gè)文件塊計(jì)算得到的MD5值與記錄的MD5值無(wú)法對(duì)應(yīng)，那么說(shuō)明此文件塊內(nèi)容被修改，其將被視為無(wú)效； 在系統(tǒng)運(yùn)行開始時(shí),Dispatchnode記錄每個(gè)Tasknode的警戒線和臨界點(diǎn)，即使后來(lái)某個(gè)Tasknode的這些參數(shù)值改變，Dispatchnode也可以通過(guò)心跳機(jī)制獲取得到； 上傳模塊服務(wù)被封裝成一個(gè)實(shí)體類QFi IeUpload，每個(gè)QFi IeUpload實(shí)體類中維護(hù)著一個(gè)上傳隊(duì)列，上傳之前需要先選擇本地文件，選擇的一個(gè)本地文件將被封裝成一個(gè)上傳任務(wù)對(duì)象，并被自動(dòng)添加到上傳任務(wù)隊(duì)列里;上傳任務(wù)對(duì)象隨機(jī)產(chǎn)生一個(gè)唯一的ID值作為文件ID，還會(huì)計(jì)算生成文件的MD5值，并保存了上傳文件的相關(guān)信息和上傳信息；添加上傳任務(wù)隊(duì)列完成后即可進(jìn)行上傳，由于添加文件的MD5計(jì)算是異步的，所以在上傳時(shí)有些比較大的文件有可能還沒(méi)有獲得MD5值，這時(shí)上傳服務(wù)組件會(huì)自動(dòng)獲取已經(jīng)數(shù)據(jù)準(zhǔn)備完成得上傳任務(wù)，然后依次執(zhí)行； 下載、刪除模塊服務(wù)和上傳模塊服務(wù)的實(shí)現(xiàn)思路一致，文件以分片的方式進(jìn)行上傳，分割后的文件塊被分散保存在LXPFS集群的Tasknode上;Tasknode的任務(wù)進(jìn)程實(shí)例在接收下載請(qǐng)求時(shí)，會(huì)根據(jù)文件共享池里的映射關(guān)系表索引文件塊，并把這些文件塊拼接形成一個(gè)完整的文件以支持組件下載； 當(dāng)用戶或應(yīng)用程序刪除某個(gè)文件時(shí)，LXPFS集群會(huì)先檢測(cè)這個(gè)文件在共享池里是否還在其他的映射;如果存在即被判斷為軟刪除，那么只是刪除用戶所屬的那條記錄和映射;要是文件不存在其他的映射，就是硬刪除，硬刪除在刪除映射的同時(shí)還會(huì)刪除文件對(duì)應(yīng)的文件塊數(shù)據(jù)。2.根據(jù)權(quán)利要求1所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于=Tasknode分為活動(dòng)節(jié)點(diǎn)和備用節(jié)點(diǎn)，control Ier服務(wù)器也分為活動(dòng)節(jié)點(diǎn)和備用節(jié)點(diǎn)。3.根據(jù)權(quán)利要求1所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于:文件以分片的方式進(jìn)行上傳后，分割后的文件塊由一個(gè)UUID值標(biāo)識(shí)，這個(gè)值即為文件塊的ID，且分割后的文件塊是有序的。4.根據(jù)權(quán)利要求1所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于:當(dāng)網(wǎng)絡(luò)中斷或上傳錯(cuò)的原因?qū)е挛募蟼饕馔庵袛鄷r(shí)會(huì)斷點(diǎn)續(xù)傳，即文件再次上傳不需要從文件的文件頭開始進(jìn)行上傳，而是從文件上傳中斷時(shí)的斷點(diǎn)位置開始上傳。5.根據(jù)權(quán)利要求1所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于:controlIer月艮務(wù)器和Tasknode能相互轉(zhuǎn)換。6.根據(jù)權(quán)利要求1所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于:所述心跳機(jī)制是指:每個(gè)Tasknode周期性地向Dispatchnode發(fā)送心跳信號(hào)，心跳信號(hào)里包含有一些用于負(fù)載均衡策略的參數(shù)值；Dispatchnode也可以主動(dòng)向Tasknode發(fā)送一個(gè)檢測(cè)信號(hào)，Tasknode收到這個(gè)信號(hào)就會(huì)收集自己的運(yùn)行情況，統(tǒng)計(jì)匯總?cè)蝿?wù)隊(duì)列的任務(wù)量、CPU和內(nèi)存等服務(wù)器的負(fù)載參數(shù)，然后發(fā)送給Dispatchnode ,Dispatchnode在獲取這些數(shù)據(jù)后，會(huì)先保存再做統(tǒng)計(jì)分析，最后應(yīng)用于負(fù)載均衡策略。7.根據(jù)權(quán)利要求6所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于:如果Tasknode節(jié)點(diǎn)上的空閑空間較富余而低于設(shè)定的臨界點(diǎn)，按照負(fù)載均衡策略系統(tǒng)就會(huì)自動(dòng)地將數(shù)據(jù)從集群中儲(chǔ)存空間緊張或者占用較大的Tasknode移動(dòng)到其他空閑的Tasknode ；如果Tasknode在某個(gè)時(shí)刻任務(wù)隊(duì)列的任務(wù)量較大，內(nèi)存和CPU使用率極高，Dispatchnode在調(diào)度任務(wù)時(shí)會(huì)盡量將任務(wù)派發(fā)給負(fù)荷較小的Tasknode。8.根據(jù)權(quán)利要求1所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于:數(shù)據(jù)訪問(wèn)時(shí)，應(yīng)用需要發(fā)送訪問(wèn)請(qǐng)求給Dispatchnode，在Dispatchnode會(huì)攔截訪問(wèn)請(qǐng)求并驗(yàn)證請(qǐng)求的來(lái)源，如果來(lái)源安全，則允許訪問(wèn)，否則拒絕訪問(wèn)。9.根據(jù)權(quán)利要求1或6或7所述的LXPFS集群分布式文件存儲(chǔ)系統(tǒng)，其特征在于，該系統(tǒng)能進(jìn)行動(dòng)態(tài)擴(kuò)展，具體為:由于Tasknode與controlIer服務(wù)器之間使用心跳機(jī)制通信，系統(tǒng)擴(kuò)展時(shí)只需要將Tasknode下的worker服務(wù)器部署好應(yīng)用程序啟動(dòng)即可;這些worker服務(wù)器會(huì)向control Ier服務(wù)器進(jìn)行心跳匯報(bào);control Ier服務(wù)器接收到這些新worker服務(wù)器的心跳匯報(bào)，會(huì)自動(dòng)完成worker服務(wù)器在系統(tǒng)中的注冊(cè)工作;注冊(cè)完成后，LXPFS集群就實(shí)現(xiàn)了一次新的擴(kuò)展而不需要重啟系統(tǒng)。
【文檔編號(hào)】H04L29/08GK106027647SQ201610339942
【公開日】2016年10月12日
【申請(qǐng)日】2016年5月20日
【發(fā)明人】李瑜, 段睿宏, 楊晴, 張勁松, 鄧安明
【申請(qǐng)人】云南云電同方科技有限公司