本發(fā)明涉及云計算領域，具體涉及一種云計算平臺下的存儲方法。
背景技術：
在IT界不斷革新的過程中,著名的摩爾定律和貝爾定律⑴共同作用,主宰這IT界的發(fā)展趨勢。摩爾定律預測處理器的速度會每18個月翻一番。然而,相比迅速增長的CPU、內存、硬盤,甚至是網(wǎng)絡帶寬,信息量的增加要快的多。由于互聯(lián)網(wǎng)的發(fā)展,對因特網(wǎng)存儲量的需求每6個月就要翻一番。
信息存儲系統(tǒng)朝著無限的帶寬(Infinite Bandwidth),無限的容量(Infinite Capacity)和無限的處理能力(Infinite processing Capability),即“3i”的方向發(fā)展。在數(shù)據(jù)高增長和企業(yè)應用快速變化的今天,網(wǎng)絡備份技術也在迅速發(fā)展以適應企業(yè)和個人需求的變化。存儲技術達到了有史以來最繁榮的時期,新的存儲技術不斷涌現(xiàn)。目前,隨著企業(yè)備份系統(tǒng)用途廣泛拓展和存儲容量的增加,在企業(yè)內部出現(xiàn)了多種存儲方式并存,如DAS(Direct Attached Storage,直連式存儲),NAS(Network Attached Storage,附網(wǎng)存儲),SAN(Storage Area Network,存儲區(qū)網(wǎng)絡),云存儲(Cloud Storage)等。
云備份是云存儲(Cloud Storage)的一個子集,可以看成是云存儲中與備份即服務(Backup as a Service,BaaS)類似的一個概念。云備份是一個網(wǎng)絡化的在線備份服務,數(shù)據(jù)備份在一些由第三方服務提供商提供的虛擬存儲池中。這些服務提供商往往是大型數(shù)據(jù)中心的運行者。用戶可以向這些提供商購買或者租賃備份空間。這些數(shù)據(jù)中心的運行著,根據(jù)用戶的需求,將自己的備份資源虛擬化成一些備份池提供給用戶使用。用戶可以自主的使用這些備份池來備份自己的文件或者數(shù)據(jù)對象。從物理上來說,這些備份資源可能是跨服務器的(一個備份池可能由多個服務器的存儲資源構成)。
云備份旳拓撲結構與云狀的局域網(wǎng)和廣域網(wǎng)類似。不同的是,云備份的主要目的是備份,而廣域網(wǎng)和互聯(lián)網(wǎng)的目的是通信。對云備份的用戶來說,云備份并不特指某一個具體的備份設備,它是由若干個不同的備份設備和備份服務器組成的一個整體。用戶使用云備份,并不是使用某一個具體的存儲設備,而是在使用由整個云備份系統(tǒng)提供的一種數(shù)據(jù)備份和訪問服務。因此,嚴格的來說,云備份并不是一種備份介質,而是一種備份服務。對使用者來說,他們無需了解云狀備份系統(tǒng)中的若干備份設備是如何協(xié)同工作以提供備份服務的。任何合法的用戶可以在任何時間,任何地點,都可以通過一根網(wǎng)絡接入線纜來使用云備份服務,訪問自己的數(shù)據(jù)。云備份系統(tǒng)的核心技術是如何通過軟件來管理和實現(xiàn)物理備份設備向備份服務的轉變。
云備份與傳統(tǒng)的備份不同,它是一個復雜的系統(tǒng),是一個由備份設備,備份管理軟件、網(wǎng)絡設備、服務器、應用軟件、公用API接口、網(wǎng)絡接入和應用軟件等多個部分組成的層次結構系統(tǒng)。各部分以備份設備為基礎,通過管理軟件、應用軟件和網(wǎng)絡接口來對用戶提供數(shù)據(jù)備份訪問的相關服務。
云備份服給務很大一部分的個人用戶和中小型企業(yè)提供了便利。個人用戶可以使用云備份服務將個人的數(shù)據(jù)備份到云端,打破了傳統(tǒng)的本地備份對個人用戶的限制。另外,由于移動終端的普及,個人用戶的移動性的需求越來越明顯,云備份服務可以使個人用戶不受時間和地點的約束。對于中小型企業(yè)來說,其IT預算一般比較緊張,更多的關心商業(yè)運作,但同時又可能有大量的備份需求。這使得它們陷入了兩難的境地,是增加預算,還是降低安全保證。云備份的出現(xiàn)使得這個矛盾可以得到較好的解決。云備份擁有云計算的即用即付的付費方式,同時也能提供安全可靠的備份服務,云備份服務也因此受中小型企業(yè)的青睞,讓他們可以將更多的精力放到其商業(yè)運作中去。
在企業(yè)應用快速變化和數(shù)據(jù)高增長的今天,網(wǎng)絡備份技術也在迅速發(fā)展以適應用戶需求的變化。云備份可以實現(xiàn)滿足用戶在任意地點、任意時間、任意方式訪問備份在云端數(shù)據(jù)服務器上的數(shù)據(jù)。對存儲需求不可預測和需要廉價存儲的組織來說,云備份可按用戶實際需求購買存儲容量,提供了良好的可擴展性。
技術實現(xiàn)要素：
至少部分的解決現(xiàn)有技術中存在的問題，本發(fā)明提出一種云計算平臺下的存儲方法，包括：
1.構建基于Hadoop分布式文件系統(tǒng)的云數(shù)據(jù)備份系統(tǒng)，所述系統(tǒng)從物理上分為客戶端、備份服務器和Hadoop分布式文件系統(tǒng)集群；
2.客戶端中保存著為本機提供服務的備份服務器的信息,當需要備份或恢復時向備份服務器發(fā)出相應請求；
3.備份服務器接收到客戶客戶端的請求，進行文件的備份和恢復；
其中，文件上傳恢復的時候，采用文件分割的方式來管理文件，文件上傳之前將文件分割成小文件塊，再將文件塊進行上傳；文件恢復的時候是先下載文件的文件塊，所有文件塊下載完成之后將文件塊合并成原來的文件。
優(yōu)選的，文件的上傳包含以下幾個步驟：
1.文件分割：將原始的用戶文件分割成幾個小的文件塊，文件分割是將大文件的存儲文件變?yōu)榱硕鄠€小文件的存儲問題，可以直接避免大文件存儲需要應對的多個技術難題；
2.文件塊加密：文件塊加密采用公鑰加密的技術，文件塊的公鑰跟私鑰都需用從Hadoop分布式文件系統(tǒng)集群獲取。文件塊加密是為了保證文件數(shù)據(jù)的包密性，對于任何云同步的應用，數(shù)據(jù)的保密性都是用戶的必備需求，用戶不會將數(shù)據(jù)存放在可能泄露的應用中；
3.文件塊壓縮：對加密后的文件塊進行壓縮；
4.文件塊校驗：文件塊經(jīng)過加密加壓之后，通過hash算法算出文件塊的hash值，文件的上傳恢復都需要通過hash值校驗，以確定文件塊在傳輸過程中沒有出現(xiàn)錯誤；同時，如果發(fā)現(xiàn)hash值已經(jīng)存在，也就是已經(jīng)有相同的文件塊存放在服務器，那么文件塊就不需要重復上傳了。使用文件校驗不僅僅可以保證數(shù)據(jù)的完整性，避免上傳一樣的文件內容可以節(jié)省服務器的存儲空間，同時減少數(shù)據(jù)流量，提高文件同步的效率。
5.文件塊上傳：文件塊通過Hadoop分布式文件系統(tǒng)集群提供的遠程接口進行同步，將文件塊上傳到Hadoop分布式文件系統(tǒng)集群，文件塊上傳結束之后，Hadoop分布式文件系統(tǒng)集群需要通過hash值來確定文件塊無錯誤。
優(yōu)選的，文件的恢復包含以下幾個步驟：
1.獲取文件塊列表：通過文件ID獲取文件對應的文件塊列表，根據(jù)文件塊的ID獲取詳細的文件塊信息，下載文件塊來間接完成文件下載功能；
2.文件塊下載：使用文件塊的ID，到指定的位置查找文件塊，將列表中的文件塊下載到本地；
3.文件塊校驗：文件塊下載完成之后，通過文件塊大小以及hash值來校驗文件塊是否成功下載；如果文件塊校驗失敗，則此文件塊無效，需要重新下載或者采用人工策略進行處理；
4.文件塊解壓：采用文件塊壓縮時相對應的文件塊解壓縮算法，對文件塊解壓縮；
5.文件塊解密：從Hadoop分布式文件系統(tǒng)集群獲取文件塊解密的私鑰，采用文件塊加密對應的解密算法對文件塊進行解密；
6.文件塊合并：文件塊完成下載、校驗、解壓、解密之后，將分離的文件塊重新合并，恢復用戶的原始文件。
優(yōu)選的，備份服務器在進行下載和上傳數(shù)據(jù)時遵從以下規(guī)則：
備份服務器需要下載數(shù)據(jù)時，立即進行；而當需要上傳數(shù)據(jù)時，如果沒有其他備份服務器上傳數(shù)據(jù)，立即上傳，否則稱之為產生沖突，等待一段時間再進行檢測以決定是否上傳，等待時間的長短由退避算法決定，退避算法具體包括：
1)當?shù)谝淮螜z測發(fā)生沖突時，設置參數(shù)L＝2；
2)退避間隔取1到L個時間片中的一個隨機數(shù)；
3)重復檢測發(fā)生沖突時，將參數(shù)L加倍，L的最大值為256,當L增加到256時，
L不再增加；
4)一旦檢測次數(shù)超過8，則立即無條件上傳數(shù)據(jù)。
優(yōu)選的，客戶端讀取文件的具體實現(xiàn)過程包括：
1.客戶端通過調用分布式文件系統(tǒng)的一個實例FileStream對象的open()方法來打開希望讀取的文件；
2.分布式文件系統(tǒng)通過RPC遠程調用名稱節(jié)點以獲得文件開頭部分的數(shù)據(jù)塊的位置，對于每個塊，名稱節(jié)點返回該塊所在的數(shù)據(jù)節(jié)點的地址，并且這些數(shù)據(jù)節(jié)點會根據(jù)其距離客戶端的遠近進行排序，如果客戶端本身也是數(shù)據(jù)節(jié)點，則直接讀取本地數(shù)據(jù)，分布式文件系統(tǒng)返回一個支持文件定位的輸入流的FSDataInputStream對象給客戶端，讓客戶端從FSDataInputStream中讀取數(shù)據(jù)；
3.客戶端調用FSDataInputStream的read()方法；
4.存儲文件開頭部分塊的數(shù)據(jù)節(jié)點地址的DFSInputStream隨即與這些塊最近的數(shù)據(jù)節(jié)點相連接，通過在數(shù)據(jù)流中重復調用read()，讀取數(shù)據(jù)從數(shù)據(jù)節(jié)點返回客戶端；
5.當?shù)谝粋€塊讀完，DFSInputStream關掉與這個數(shù)據(jù)節(jié)點的連接，然后開始第二個塊的操作；
6.客戶端從流中讀取數(shù)據(jù)時，塊是按照DFSInputStream打開與數(shù)據(jù)節(jié)點的新連接的順序讀取的，DFSInputStream也會調用名稱節(jié)點來檢索下一組需要的塊的數(shù)據(jù)節(jié)點的位置，客戶端完成數(shù)據(jù)讀取后，調用FSDataInputStream的close()方法關閉數(shù)據(jù)流。
優(yōu)選的，在文件讀取過程中，如果客戶端從一個數(shù)據(jù)節(jié)點上讀取出錯，則選擇下一個離它最近的數(shù)據(jù)節(jié)點，同時記住這個失敗的數(shù)據(jù)節(jié)點，在讀取后面的塊的時候不再選擇這個數(shù)據(jù)節(jié)點。
優(yōu)選的，客戶端寫入文件的具體實現(xiàn)過程包括：
1.客戶端通過調用分布式文件系統(tǒng)的create()方法來創(chuàng)建文件；
2.分布式文件系統(tǒng)通過RPC遠程調用名稱節(jié)點，在文件系統(tǒng)的名字空間里創(chuàng)建一個新文件，此時這個文件還沒有任何塊與之相聯(lián)系；名稱節(jié)點執(zhí)行檢查以確保這個文件不會已經(jīng)存在，并且客戶端擁有創(chuàng)建此文件的權限；如果上述檢查通過，名稱節(jié)點會生成一個新文件的記錄；否則文件創(chuàng)建失敗并向客戶端拋出一個異常；分布式文件系統(tǒng)返回一個FSDataOutputStream,讓客戶端開始寫入數(shù)據(jù)，F(xiàn)SDataOutputStream控制一個DFSOutputStream，DFSOutputStream負責處理數(shù)據(jù)節(jié)點和名稱節(jié)點之間的通信；
3.當客戶端寫入數(shù)據(jù)時，DFSDataOutputStream把要寫入的數(shù)據(jù)分成很多包，并將它們寫入內部的數(shù)據(jù)隊列，數(shù)據(jù)隊列中的數(shù)據(jù)由數(shù)據(jù)流來讀取，數(shù)據(jù)流讓名稱節(jié)點找出一個合適的數(shù)據(jù)節(jié)點列表，并要求這些數(shù)據(jù)節(jié)點分配一些新的塊以存儲作為副本而復制的數(shù)據(jù)，這個數(shù)據(jù)節(jié)點列表組成了一個管線；
4.FSDataInputStream將包分流給管線中第一個的數(shù)據(jù)節(jié)點，這個節(jié)點會對包進行存儲并且發(fā)送給管線中的第二個數(shù)據(jù)節(jié)點，第二個數(shù)據(jù)節(jié)點存儲包并且傳給管線中第三個數(shù)據(jù)節(jié)點，直至將包傳給管線中的最后一個數(shù)據(jù)節(jié)點；
5.DFSOutputStream有一個內部的包隊列來等待數(shù)據(jù)節(jié)點收到確認，稱為確認隊列，只有當管線中所有的數(shù)據(jù)節(jié)點都返回寫入成功，這個包才算寫成功，發(fā)送確認給DFSOutputStream，包被移出確認隊列，然后開始下一個包的寫入；
如果在有數(shù)據(jù)寫入期間,數(shù)據(jù)節(jié)點發(fā)生故障,則會執(zhí)行下面的操作：首先管線被關閉，確認隊列中的任何包都會被添加回數(shù)據(jù)隊列的前面，以確保數(shù)據(jù)節(jié)點從失敗的節(jié)點處是順流的，不會漏掉任意一個包，當前的塊在正常工作的數(shù)據(jù)節(jié)點中被給予一個新的身份并聯(lián)系名稱節(jié)點，以便能在故障數(shù)據(jù)節(jié)點后期恢復時其中的部分數(shù)據(jù)塊會被刪除；故障數(shù)據(jù)節(jié)點會從管線中刪除并且余下塊的數(shù)據(jù)會被寫入管線中的兩個好的數(shù)據(jù)節(jié)點；名稱節(jié)點注意到塊副本不足時，會在另一個節(jié)點上安排創(chuàng)建一個副本；隨后，后續(xù)的塊會繼續(xù)正常處理；
6.客戶端完成數(shù)據(jù)的寫入后，就會在FSDataInputStream中調用close()；
7.在塊完成復制到最少的份數(shù)之后，名字節(jié)點將成功返回。
本發(fā)明提出了一種新的基于云計算平臺的存儲方法，提高了存儲文件的效率。
附圖說明
圖1為本發(fā)明一種云計算平臺下的存儲方法的流程圖；
具體實施方式
下面將結合本發(fā)明的附圖，對本發(fā)明的技術方案進行清楚、完整地描述。這里將詳細地對示例性實施例進行說明，其示例表示在附圖中。下面的描述涉及附圖時，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實施例中所描述的實施方式并不代表與本發(fā)明相一致的所有實施方式。相反，它們僅是與如所附權利要求書中所詳述的、本發(fā)明的一些方面相一致的裝置和方法的例子。
參見圖1，本發(fā)明提出了一種云計算平臺下的存儲方法，包括：
1.構建基于Hadoop分布式文件系統(tǒng)的云數(shù)據(jù)備份系統(tǒng)，所述系統(tǒng)從物理上分為客戶端、備份服務器和Hadoop分布式文件系統(tǒng)集群；
客戶端是企業(yè)中眾多需要數(shù)據(jù)備份/恢復服務的計算機節(jié)點，按照地域、系統(tǒng)類別等分成若干個群，當需要進行數(shù)據(jù)備份或者恢復時，他們向負責本群的備份服務器提出請求，得到許可后進行文件的備份和恢復操作。客戶端用于實現(xiàn)數(shù)據(jù)備份恢復，包括文件打包、壓縮策略，數(shù)據(jù)的備份和恢復。
備份服務器是客戶端和Hadoop分布式文件系統(tǒng)集群間數(shù)據(jù)備份恢復的橋梁，由多個高性能、大存儲量服務器構成，每個服務器負責一個客戶端群。他們接受客戶端的備份恢復請求，緩存客戶端的備份數(shù)據(jù)，根據(jù)備份數(shù)據(jù)的不同情況，分別對他們進行合并、分割、壓縮后上傳到Hadoop分布式文件系統(tǒng)集群進行備份，同時保存客戶端備份文件的映像表，當客戶端提出恢復請求時，從Hadoop分布式文件系統(tǒng)集群中讀取備份文件，按照文件映像表發(fā)送給客戶端。
備份服務器包含以下幾個具體功能模塊:
(1)備份管理模塊：系統(tǒng)的核心功能模塊，主要負責文件的備份管理工作；
(2)恢復管理模塊：負責備份文件的恢復工作；
(3)安全管理模塊：該模塊的功能包括控制文件的傳輸安全及存儲安全，對客戶端的認證與授權；
(4)目錄管理模塊:該模塊負責是客戶端管理和備份文件目錄管理。文件備份信息表負責管理備份文件的目錄，客戶信息表負責管理備份服務器所負責的所有客戶；
(5)用戶接口模塊:提供友好的用戶操作界面，用于顯示、配置備份操作信息，用戶可以根據(jù)自己的需要選擇備份方式；
(6)同步處理模塊：該模塊主要負責文件的同步處理,用于監(jiān)視客戶端文件的變化,進行客戶端和Hadoop分布式文件系統(tǒng)集群端之間的同步工作,當監(jiān)測到客戶端文件改變時,將Hadoop分布式文件系統(tǒng)集群上的相應文件進行同步更新。
Hadoop分布式文件系統(tǒng)集群由安裝了Hadoop分布式文件系統(tǒng)軟件的計算機組成，在Hadoop分布式文件系統(tǒng)軟件的架構下，通過配置向多個備份服務器提供上傳、下載服務，實現(xiàn)系統(tǒng)的核心功能。
Hadoop分布式文件系統(tǒng)集群采用主/從結構，由一個名字節(jié)點Namenode和一定數(shù)量的數(shù)據(jù)節(jié)點Datanodes組成，Namenode作為為中心服務器負責管理文件系統(tǒng)的名字空間(namespace)以及客戶對文件的訪問；Namenode執(zhí)行文件系統(tǒng)的打開、關閉、重命名文件或目錄這些名字空間操作；也負責確定數(shù)據(jù)塊到特定Datanode節(jié)點的映射，Namenode由企業(yè)云中具有較高性能的服務器配置而成，以實現(xiàn)高效的元數(shù)據(jù)管理，避免性能瓶頸，DataNode用于存儲數(shù)據(jù)，由企業(yè)內部大量廉價計算機配置而成，并且可以根據(jù)備份數(shù)據(jù)的規(guī)模進行動態(tài)擴展。備份時文件被分成一個或多個數(shù)據(jù)塊，這些塊存儲在一組Datanode上。Datanode負責對文件系統(tǒng)客戶端的讀寫請求進行處理，并在Namenode的統(tǒng)一調度下進行數(shù)據(jù)塊的創(chuàng)建、刪除和復制等操作。
基于Hadoop分布式文件系統(tǒng)的云數(shù)據(jù)備份系統(tǒng)應用備份服務器作為客戶端與備份集群的橋梁出于以下考慮：備份服務器可以屏蔽客戶端對備份集群的直接訪問，提高備份集群的安全性，同時在備份服務器和客戶端之間通過防火墻、安全信道等技術手段實現(xiàn)數(shù)據(jù)安全，進而保證整個系統(tǒng)的安全；備份服務器可以暫存數(shù)據(jù)，并根據(jù)備份集群的負載狀況，網(wǎng)絡狀況決定在合適的時間上傳數(shù)據(jù)，從而保證備份集群的負載平衡；雖然在特殊情況下，備份服務器由于大量客戶端的備份/恢復請求可能成為系統(tǒng)的瓶頸，但通過應用高性能的服務器作為備份服務器及客戶端的合理調度可以最大可能地避免此種情況的發(fā)生；向Hadoop分布式文件系統(tǒng)集群上傳、下載文件需要在計算機上安裝Hadoop特定組件，這對數(shù)量眾多、水平參差不齊的客戶來說是不現(xiàn)實的，通過在備份服務器上收集用戶需備份的數(shù)據(jù)，并在其上安裝Hadoop組件實現(xiàn)備份、恢復功能，易于實現(xiàn)并充分發(fā)揮Hadoop分布式文件系統(tǒng)的功能。
2.客戶端中保存著為本機提供服務的備份服務器的信息,當需要備份或恢復時向備份服務器發(fā)出相應請求；
客戶端模塊備份數(shù)據(jù)前，應用tar、winrar等工具將所有數(shù)據(jù)文件打包成一個備份文件，按照“客戶Id-備份日期-bak”的規(guī)則命名；同時進行壓縮以節(jié)省存儲空間、減少備份恢復時間。
客戶端文件的備份過程具體為：
B1調用工具對備份數(shù)據(jù)打包；
B2調用壓縮工具壓縮打包文件；
B3向備份服務器提出備份請求；
B4判斷備份請求是否通過；
B5如備份請求通過，將數(shù)據(jù)文件上傳至備份服務器。
客戶端文件的恢復過程具體為：
H1向備份服務器提出恢復請求；
H2判斷恢復請求是否通過；
H3如恢復請求通過，下載數(shù)據(jù)文件；
H4調用工具解壓縮打包文件；
H5調用工具解包備份文件。
3.備份服務器接收到客戶客戶端的請求，進行文件的備份和恢復；
3.1備份服務器的備份操作具體包括：
備份服務器接收到客戶客戶端的備份請求后,首先對客戶端進行識別認證，認證通過后接收客戶端上傳的備份文件，備份文件上傳完畢后，備份服務器將備份文件加上時間戳編號后暫存，并將備份文件的信息記入備份文件信息表，然后將文件名作為參數(shù)調用云數(shù)據(jù)上傳算法上傳數(shù)據(jù)到Hadoop分布式文件系統(tǒng)集群。
云數(shù)據(jù)上傳算法首先檢測用戶上傳文件大小是否大于等于閾值th_size，如果大于等于則上傳該文件到Hadoop分布式文件系統(tǒng)集群，上傳成功后將文件備份數(shù)據(jù)信息表中對應的上傳標志置為真，填寫上傳文件名，刪除備份服務器上的文件；如果文件大小小于th_size，則讀取備份文件信息表，得到所有未上傳備份文件的信息，計算全部未上傳文件的大小，如果大于等于th_size,則將所有未上傳文件打包成一個文件，按照“文件名1-文件2…-文件名n”的方式對該文件命名后上傳，上傳成功后，將備份文件信息表中對應的上傳標志位置為真，填寫上傳文件名后刪除文件；如果全部為上傳文件大小依然小于th_size，則暫時不將文件上傳至Hadoop分布式文件系統(tǒng)集群。
3.2備份服務器的恢復操作具體包括：
備份服務器接收到客戶端的恢復請求后,首先對客戶端進行識別認證，認證通過后,檢查備份文件信息表,如果備份文件暫存在本地,則從備份服務器上發(fā)送文件給客戶端；如果備份文件存于Hadoop分布式文件系統(tǒng)集群中,則從Hadoop分布式文件系統(tǒng)集群中下載文件后,再發(fā)送給客戶端，如果備份文件是由多個文件打包而成，則還需要對文件解包，再發(fā)送給客戶端。
備份服務器在進行下載和上傳數(shù)據(jù)時遵從以下規(guī)則：
備份服務器需要下載數(shù)據(jù)時，立即進行；而當需要上傳數(shù)據(jù)時，如果沒有其他備份服務器上傳數(shù)據(jù)，立即上傳，否則稱之為產生沖突，等待一段時間再進行檢測以決定是否上傳，等待時間的長短由退避算法決定，退避算法具體包括：
1)當?shù)谝淮螜z測發(fā)生沖突時，設置參數(shù)L＝2；
2)退避間隔取1到L個時間片中的一個隨機數(shù)；
3)重復檢測發(fā)生沖突時，將參數(shù)L加倍，L的最大值為256,當L增加到256時，
L不再增加；
4)一旦檢測次數(shù)超過8，則立即無條件上傳數(shù)據(jù)。
通過應用退避算法，當備份服務器檢測沖突較多時，產生較長等待時間的概率越大，從而保證在系統(tǒng)重負載時，盡可能少的對系統(tǒng)進行測試計算；同時當備份服務器退避次數(shù)超過8次時立即上傳以保證公平性。
大文件的同步問題是云同步的難點。大文件同步不僅僅在云端要占據(jù)大量的存儲空間，大文件的上傳下載有很多難題需要解決，基于網(wǎng)絡傳輸?shù)牟环€(wěn)定性，文件安全性，文件校驗，文件加密壓縮等問題。目前國內外大多數(shù)的云同步應用只支持100MB以下的文件同步。大文件的同步主要面臨以下幾個問題：1.網(wǎng)絡傳輸?shù)牟环€(wěn)定性；2.文件傳輸?shù)陌踩裕?.網(wǎng)絡帶寬的限制；4.大文件更新的效率問題。
為此，本發(fā)明采用文件分割的技術，將文件分割成多個獨立的文件塊，提高文件同步處理的效率。文件經(jīng)過分割之后，文件塊的大小在一個可控的范圍內，無論原始文件本身多大，分割后的文件塊都在云存儲系統(tǒng)可接受的范圍內。這樣Hadoop分布式文件系統(tǒng)集群的文件存儲系統(tǒng)就能夠快速的處理云同步的文件存儲問題，對相應的文件塊進行管理避免Hadoop分布式文件系統(tǒng)集群出現(xiàn)大的文件塊，造成Hadoop分布式文件系統(tǒng)集群存儲系統(tǒng)的性能問題以及Hadoop分布式文件系統(tǒng)集群存儲空間的浪費。
文件上傳恢復的時候，采用文件分割的方式來管理文件。文件上傳之前將文件分割成小文件塊，再將文件塊進行上傳；文件恢復的時候是先下載文件的文件塊，所有文件塊下載完成之后將文件塊合并成原來的文件。
文件的上傳包含以下幾個步驟：
1.文件分割：將原始的用戶文件分割成幾個小的文件塊，文件分割是將大文件的存儲文件變?yōu)榱硕鄠€小文件的存儲問題，可以直接避免大文件存儲需要應對的多個技術難題；
2.文件塊加密：文件塊加密采用公鑰加密的技術，文件塊的公鑰跟私鑰都需用從Hadoop分布式文件系統(tǒng)集群獲取。文件塊加密是為了保證文件數(shù)據(jù)的包密性，對于任何云同步的應用，數(shù)據(jù)的保密性都是用戶的必備需求，用戶不會將數(shù)據(jù)存放在可能泄露的應用中；
3.文件塊壓縮：對加密后的文件塊進行壓縮；
4.文件塊校驗：文件塊經(jīng)過加密加壓之后，通過hash算法算出文件塊的hash值，文件的上傳恢復都需要通過hash值校驗，以確定文件塊在傳輸過程中沒有出現(xiàn)錯誤；同時，如果發(fā)現(xiàn)hash值已經(jīng)存在，也就是已經(jīng)有相同的文件塊存放在服務器，那么文件塊就不需要重復上傳了。使用文件校驗不僅僅可以保證數(shù)據(jù)的完整性，避免上傳一樣的文件內容可以節(jié)省服務器的存儲空間，同時減少數(shù)據(jù)流量，提高文件同步的效率。
5.文件塊上傳：文件塊通過Hadoop分布式文件系統(tǒng)集群提供的遠程接口進行同步，將文件塊上傳到Hadoop分布式文件系統(tǒng)集群，文件塊上傳結束之后，Hadoop分布式文件系統(tǒng)集群需要通過hash值來確定文件塊無錯誤。
文件的恢復包含以下幾個步驟：
1.獲取文件塊列表：通過文件ID獲取文件對應的文件塊列表，根據(jù)文件塊的ID獲取詳細的文件塊信息，下載文件塊來間接完成文件下載功能；
2.文件塊下載：使用文件塊的ID，到指定的位置查找文件塊，將列表中的文件塊下載到本地；
3.文件塊校驗：文件塊下載完成之后，通過文件塊大小以及hash值來校驗文件塊是否成功下載；如果文件塊校驗失敗，則此文件塊無效，需要重新下載或者采用人工策略進行處理；
4.文件塊解壓：采用文件塊壓縮時相對應的文件塊解壓縮算法，對文件塊解壓縮；
5.文件塊解密：從Hadoop分布式文件系統(tǒng)集群獲取文件塊解密的私鑰，采用文件塊加密對應的解密算法對文件塊進行解密；
6.文件塊合并：文件塊完成下載、校驗、解壓、解密之后，將分離的文件塊重新合并，恢復用戶的原始文件。
當監(jiān)測到客戶端的文件發(fā)生改變時，本發(fā)明使用以下方式同步更新Hadoop分布式文件系統(tǒng)集群上相應的文件：
1.當監(jiān)測到客戶端的文件CFold變更為文件CFnew時，將發(fā)生改變的文件ID發(fā)送給Hadoop分布式文件系統(tǒng)集群；
2.根據(jù)客戶端發(fā)來的文件ID，Hadoop分布式文件系統(tǒng)集群將CFold對應的SFold劃分為大小為B的塊，SFold[(i-1)B,iB-1],表示文件從偏移地址(i-1)B到iB-1的內容，其中，i的取值為[1,2,3,……,N],N是文件SFold劃分的塊數(shù)；然后計算每個塊Bi的的兩個哈希值：qi＝hq(Bi)和ri＝hm(Bi)，其中，hq(Bi)表示對塊Bi進行alder-32校驗計算，hm(Bi)表示對塊Bi進行MD5校驗計算，然后將兩個校驗值發(fā)送給客戶端；
3.客戶端接收Hadoop分布式文件系統(tǒng)集群發(fā)來的每個塊的兩個哈希值(qi，ri)，建立哈希表；
4.客戶端遍歷文件CFnew，從偏移地址j＝0開始，重復執(zhí)行以下步驟4.1-4.4
4.1計算hq(CFnew[j,j+B-1])；
4.2從哈希表中查找是否具有匹配的哈希值；
4.3如果找到匹配哈希值，計算hm(CFnew[j,j+B-1])，如果hm也匹配，則發(fā)送該塊的偏移地址j和該塊的大小信息給分布式文件系統(tǒng)集群，并對j進行加B操作；
4.4如果沒有找到匹配哈希值，或者hm不匹配，則傳輸CFnew[j]給Hadoop分布式文件系統(tǒng)集群，CFnew[j]表示文件CFnew在偏移地址j處的內容，j＝j+1；
5.Hadoop分布式文件系統(tǒng)集群根據(jù)客戶端傳送的內容和SFold構建出與CFnew對應的文件SFnew。
上述同步更新方式計算量小、速度快。對于文件修改量很小的情況，還可以對上述算法進行進一步的改進。當CFnew的第i塊與SFold的第j塊匹配時,極有可能CFnew的第i+1塊與SFold的第j+1塊匹配,而上述算法每次找到一個匹配的塊時要傳輸?shù)臄?shù)據(jù)次數(shù)過多,對帶寬的利用性不高。
當監(jiān)測到客戶端的文件發(fā)生改變時，本發(fā)明還可以使用以下方式同步更新Hadoop分布式文件系統(tǒng)集群上相應的文件：
1.當監(jiān)測到客戶端的文件CFold變更為文件CFnew時，將發(fā)生改變的文件ID發(fā)送給Hadoop分布式文件系統(tǒng)集群；
2.根據(jù)客戶端發(fā)來的文件ID，Hadoop分布式文件系統(tǒng)集群將CFold對應的SFold劃分為大小為B的塊，SFold[(i-1)B,iB-1],表示文件從偏移地址(i-1)B到iB-1的內容，其中，i的取值為[1,2,3,……,N],N是文件SFold劃分的塊數(shù)；然后計算每個塊Bi的的兩個哈希值：qi＝hq(Bi)和ri＝hm(Bi)，其中，hq(Bi)表示對塊Bi進行alder-32校驗計算，hm(Bi)表示對塊Bi進行MD5校驗計算，然后將兩個校驗值發(fā)送給客戶端；
3.客戶端接收Hadoop分布式文件系統(tǒng)集群發(fā)來的每個塊的兩個哈希值(qi，ri)，建立哈希表；
4.客戶端遍歷文件CFnew，從偏移地址j＝0開始，重復執(zhí)行以下步驟4.1-4.4
4.1計算hq(CFnew[j,j+B-1])；
4.2從哈希表中查找是否具有匹配的哈希值；
4.3如果找到匹配哈希值，計算hm(CFnew[j,j+B-1])，如果hm也匹配，則將該塊的偏移地址j和該塊的大小信息存儲到列表MatchList中，并對j進行加B操作；
4.4如果沒有找到匹配哈希值，或者hm不匹配，則將CFnew[j]存儲到列表MatchList中，CFnew[j]表示文件CFnew在偏移地址j處的內容,判斷列表MatchList中所存儲的CFnew[j]總容量是否達到Hadoop分布式文件系統(tǒng)集群中的最小存儲單元CK，如果是，則將列表MatchList中存儲的內容發(fā)送給Hadoop分布式文件系統(tǒng)集群并繼續(xù)以下操作，否則直接繼續(xù)以下操作，j＝j+1；
5.Hadoop分布式文件系統(tǒng)集群根據(jù)客戶端傳送的內容和SFold構建出與CFnew對應的文件SFnew。
本發(fā)明中，客戶端讀取文件的具體實現(xiàn)過程包括：
1.客戶端通過調用分布式文件系統(tǒng)的一個實例FileStream對象的open()方法來打開希望讀取的文件；
2.分布式文件系統(tǒng)通過RPC遠程調用名稱節(jié)點以獲得文件開頭部分的數(shù)據(jù)塊的位置，對于每個塊，名稱節(jié)點返回該塊所在的數(shù)據(jù)節(jié)點的地址，并且這些數(shù)據(jù)節(jié)點會根據(jù)其距離客戶端的遠近進行排序，如果客戶端本身也是數(shù)據(jù)節(jié)點，則直接讀取本地數(shù)據(jù)，分布式文件系統(tǒng)返回一個支持文件定位的輸入流的FSDataInputStream對象給客戶端，讓客戶端從FSDataInputStream中讀取數(shù)據(jù)；
3.客戶端調用FSDataInputStream的read()方法；
4.存儲文件開頭部分塊的數(shù)據(jù)節(jié)點地址的DFSInputStream隨即與這些塊最近的數(shù)據(jù)節(jié)點相連接，通過在數(shù)據(jù)流中重復調用read()，讀取數(shù)據(jù)從數(shù)據(jù)節(jié)點返回客戶端；
5.當?shù)谝粋€塊讀完，DFSInputStream關掉與這個數(shù)據(jù)節(jié)點的連接，然后開始第二個塊的操作；
6.客戶端從流中讀取數(shù)據(jù)時，塊是按照DFSInputStream打開與數(shù)據(jù)節(jié)點的新連接的順序讀取的，DFSInputStream也會調用名稱節(jié)點來檢索下一組需要的塊的數(shù)據(jù)節(jié)點的位置，客戶端完成數(shù)據(jù)讀取后，調用FSDataInputStream的close()方法關閉數(shù)據(jù)流。
在文件讀取過程中，如果客戶端從一個數(shù)據(jù)節(jié)點上讀取出錯，則選擇下一個離它最近的數(shù)據(jù)節(jié)點。同時記住這個失敗的數(shù)據(jù)節(jié)點，在讀取后面的塊的時候不再選擇這個數(shù)據(jù)節(jié)點。
這個設計的一個重要方面是：客戶端直接聯(lián)系數(shù)據(jù)節(jié)點接收數(shù)據(jù)，并且客戶端通過名字節(jié)點直接導向包含所需數(shù)據(jù)的最佳數(shù)據(jù)節(jié)點。這樣的設計可以使Hadoop分布式文件系統(tǒng)擴展而適應大量的客戶端，因為數(shù)據(jù)傳輸線路是通過集群中的所有數(shù)據(jù)節(jié)點的；名稱節(jié)點只需要提供相應塊的位置查詢服務即可，并且名稱節(jié)點是將塊的位置信息存放在內存中的，這樣效率就非常高，名稱節(jié)點不需要提供數(shù)據(jù)傳輸服務，否則數(shù)據(jù)服務將隨著客戶端的增加將很快成為瓶頸。
本發(fā)明中，客戶端寫入文件的具體實現(xiàn)過程包括：
1.客戶端通過調用分布式文件系統(tǒng)的create()方法來創(chuàng)建文件；
2.分布式文件系統(tǒng)通過RPC遠程調用名稱節(jié)點，在文件系統(tǒng)的名字空間里創(chuàng)建一個新文件，此時這個文件還沒有任何塊與之相聯(lián)系；名稱節(jié)點執(zhí)行檢查以確保這個文件不會已經(jīng)存在，并且客戶端擁有創(chuàng)建此文件的權限；如果上述檢查通過，名稱節(jié)點會生成一個新文件的記錄；否則文件創(chuàng)建失敗并向客戶端拋出一個異常；分布式文件系統(tǒng)返回一個FSDataOutputStream,讓客戶端開始寫入數(shù)據(jù)，F(xiàn)SDataOutputStream控制一個DFSOutputStream，DFSOutputStream負責處理數(shù)據(jù)節(jié)點和名稱節(jié)點之間的通信；
3.當客戶端寫入數(shù)據(jù)時，DFSDataOutputStream把要寫入的數(shù)據(jù)分成很多包，并將它們寫入內部的數(shù)據(jù)隊列，數(shù)據(jù)隊列中的數(shù)據(jù)由數(shù)據(jù)流來讀取，數(shù)據(jù)流讓名稱節(jié)點找出一個合適的數(shù)據(jù)節(jié)點列表，并要求這些數(shù)據(jù)節(jié)點分配一些新的塊以存儲作為副本而復制的數(shù)據(jù)，這個數(shù)據(jù)節(jié)點列表組成了一個管線；
4.FSDataInputStream將包分流給管線中第一個的數(shù)據(jù)節(jié)點，這個節(jié)點會對包進行存儲并且發(fā)送給管線中的第二個數(shù)據(jù)節(jié)點，第二個數(shù)據(jù)節(jié)點存儲包并且傳給管線中第三個數(shù)據(jù)節(jié)點，直至將包傳給管線中的最后一個數(shù)據(jù)節(jié)點；
5.DFSOutputStream有一個內部的包隊列來等待數(shù)據(jù)節(jié)點收到確認，稱為確認隊列，只有當管線中所有的數(shù)據(jù)節(jié)點都返回寫入成功，這個包才算寫成功，發(fā)送確認給DFSOutputStream，包被移出確認隊列，然后開始下一個包的寫入；
如果在有數(shù)據(jù)寫入期間,數(shù)據(jù)節(jié)點發(fā)生故障,則會執(zhí)行下面的操作：首先管線被關閉，確認隊列中的任何包都會被添加回數(shù)據(jù)隊列的前面，以確保數(shù)據(jù)節(jié)點從失敗的節(jié)點處是順流的，不會漏掉任意一個包，當前的塊在正常工作的數(shù)據(jù)節(jié)點中被給予一個新的身份并聯(lián)系名稱節(jié)點，以便能在故障數(shù)據(jù)節(jié)點后期恢復時其中的部分數(shù)據(jù)塊會被刪除；故障數(shù)據(jù)節(jié)點會從管線中刪除并且余下塊的數(shù)據(jù)會被寫入管線中的兩個好的數(shù)據(jù)節(jié)點；名稱節(jié)點注意到塊副本不足時，會在另一個節(jié)點上安排創(chuàng)建一個副本；隨后，后續(xù)的塊會繼續(xù)正常處理；
6.客戶端完成數(shù)據(jù)的寫入后，就會在FSDataInputStream中調用close()；
7.在塊完成復制到最少的份數(shù)之后，名字節(jié)點將成功返回。
本發(fā)明提出了一種新的基于云計算平臺的存儲方法，提高了文件存儲的效率。
本領域技術人員在考慮說明書及實踐這里公開的發(fā)明后，將容易想到本發(fā)明的其它實施方案。本申請旨在涵蓋本發(fā)明的任何變型、用途或者適應性變化，這些變型、用途或者適應性變化遵循本發(fā)明的一般性原理并包括本發(fā)明未公開的本技術領域中的公知常識或慣用技術手段。
應當理解的是，本發(fā)明并不局限于上面已經(jīng)描述并在附圖中示出的精確結構，并且可以在不脫離其范圍進行各種修改和改變。本發(fā)明的范圍僅由所附的權利要求來限制。