文件秒傳系統(tǒng)在云存儲環(huán)境下的設計與實現(xiàn)

胡 渝 蘋

文件秒傳系統(tǒng)在云存儲環(huán)境下的設計與實現(xiàn)

胡 渝 蘋

(重慶水利電力職業(yè)技術(shù)學院 重慶 402160)

針對云存儲環(huán)境下用戶數(shù)據(jù)上傳速度慢的問題，設計一個文件秒傳系統(tǒng)FSTS(File Second Transmission System)。該系統(tǒng)基于云存儲服務器充足的數(shù)據(jù)資源，建立元數(shù)據(jù)資源庫，通過將文件設計為資源共享的方式實現(xiàn)數(shù)據(jù)秒傳，元數(shù)據(jù)資源庫將云存儲服務器上的數(shù)據(jù)通過唯一標識數(shù)據(jù)內(nèi)容的字段組織起來， 以此來保證該資源庫中沒有重復的數(shù)據(jù)。用戶在上傳數(shù)據(jù)到云存儲服務器時，如果該數(shù)據(jù)的唯一標識已經(jīng)存在于元數(shù)據(jù)資源庫，那么只需要增加該記錄的引用計數(shù)即可完成用戶數(shù)據(jù)的上傳，而無需通過網(wǎng)絡傳輸數(shù)據(jù)的任何內(nèi)容，即實現(xiàn)了文件的邏輯上傳，并且保證了對數(shù)據(jù)的后續(xù)操作都是正常的。實驗結(jié)果表明，該文件秒傳系統(tǒng)可以很好地提高數(shù)據(jù)的上傳速度以及提高云存儲服務器存儲空間的利用率，該方案在云存儲環(huán)境下是可行的、有效的。

文件秒傳 云存儲 元數(shù)據(jù) 引用計數(shù)

0 引 言

云計算已經(jīng)廣泛地應用到了各行各業(yè)，云存儲也隨之得到了更加廣泛的關(guān)注與應用[1]。用戶在使用云存儲服務時，不僅關(guān)注數(shù)據(jù)的安全性、可靠性、容災備份、可用性等，而且對數(shù)據(jù)的上傳速度以及數(shù)據(jù)的下載速度也有一定的要求[2]，當然是數(shù)據(jù)上傳速度越快越好。每個用戶都希望自己的數(shù)據(jù)可以更快更安全地上傳到云端存儲服務器，但是，限于網(wǎng)絡傳輸速度、帶寬、磁盤讀取速度、云端存儲速度等限制，使得用戶的數(shù)據(jù)遲遲無法完成上傳功能[3,4]。如果網(wǎng)絡環(huán)境較差的話，對于幾百MB大小的文件來說，都有可能消耗幾個小時甚至幾十個小時的傳輸時間，這對用戶來說，是無法接受的。如何提高在現(xiàn)有的使用環(huán)境下用戶數(shù)據(jù)的上傳速度，是一個十分棘手的問題[5]。

文件秒傳系統(tǒng)就是為了最大限度地解決數(shù)據(jù)上傳速度慢的問題，它采用各種手段來實現(xiàn)數(shù)據(jù)的快速上傳?，F(xiàn)有的解決方案主要是通過數(shù)據(jù)分割、數(shù)據(jù)內(nèi)部復制、多線程并行處理等手段實現(xiàn)文件快速上傳的。文獻[6]通過將文件分成多個不相交的數(shù)據(jù)段，采用多進程實現(xiàn)文件的并行上傳；文獻[7]采用了按照固定長度分割文件，然后依次判斷每個長度區(qū)間在服務器是否已經(jīng)存在，如果存在則通過服務器內(nèi)部實現(xiàn)數(shù)據(jù)復制，如果不存在，則通過單進程實現(xiàn)該數(shù)據(jù)塊的上傳；文獻[8]采用通過設計分布式服務器，將文件分割成多個數(shù)據(jù)塊，分別上傳至不同的服務器上；文獻[9]實現(xiàn)了數(shù)據(jù)塊的判重功能，將重復的數(shù)據(jù)塊由服務器內(nèi)部實現(xiàn)復制以模擬上傳功能，對于不重復的數(shù)據(jù)塊，采用多線程完成上傳。這些解決方案在一定程度上可以加速文件上傳的速度，但是，并不能從根本上解決問題，它仍極大地依賴于磁盤轉(zhuǎn)速、網(wǎng)絡速度、帶寬等因素[10]。在這些方案中，無法排除服務器端重復的文件，在海量數(shù)據(jù)情況下，服務器端的文件大量重復，會造成大量的空間浪費[11]。

為了解決用戶上傳文件速度受限的問題，提高用戶上傳文件的速度。本文充分利用云存儲的優(yōu)勢，即大數(shù)據(jù)，設計了一個快速存儲系統(tǒng)，讓用戶的某些數(shù)據(jù)可以在極短的時間內(nèi)完成上傳工作，本文稱這種設計為基于大數(shù)據(jù)的文件秒傳系統(tǒng)FSTS。

1 FSTS的設計與實現(xiàn)

FSTS是本文設計的一種實現(xiàn)文件秒傳功能的系統(tǒng)，這種系統(tǒng)可以讓用戶在極短的時間內(nèi)完成數(shù)據(jù)上傳的功能。這種系統(tǒng)的實現(xiàn)需要有海量的數(shù)據(jù)為基礎(chǔ)，這些數(shù)據(jù)將用來作為用戶的數(shù)據(jù)備用庫。

本文設計的FSTS是基于云存儲的大數(shù)據(jù)而存在的，它依賴于云存儲環(huán)境，并且該系統(tǒng)的效率與云存儲的數(shù)據(jù)存在有很大的關(guān)系。用戶上傳數(shù)據(jù)的操作能否在極短的時間內(nèi)完成，取決于該數(shù)據(jù)在云存儲系統(tǒng)中是否存在。

本文將對FSTS系統(tǒng)的設計與實現(xiàn)作詳細介紹，具體包括：總體的設計方案、元數(shù)據(jù)的存儲設計方案、文件上傳流程設計、文件下載流程設計、文件刪除流程設計以及文件清理方案設計等。

1.1 總體架構(gòu)設計

FSTS的總體設計方案如圖1所示。從圖1可以看出，F(xiàn)STS主要組成部分有Client、MySQL-View Cluster、MySQL-Metadata Cluster、負載均衡系統(tǒng)、Cache存儲服務器、分布式存儲HDFS(Hadoop Distributed File System)六部分構(gòu)成。

圖1 FSTS總體架構(gòu)設計

其中Client是客戶端部分，用戶通過Client提供的接口完成數(shù)據(jù)的上傳、下載、刪除等功能，通過TCP/IP協(xié)議與服務器進行安全可靠的交互工作，是服務器提供給用戶的唯一接口；MySQL-View Cluster是用戶視圖存儲服務器集群，該集群使用MySQL數(shù)據(jù)庫存儲數(shù)據(jù)，該集群通過負載均衡系統(tǒng)統(tǒng)一調(diào)度，用來存儲用戶數(shù)據(jù)的元數(shù)據(jù)；MySQL-Metadata Cluster是云存儲系統(tǒng)存儲服務器集群，該集群使用MySQL數(shù)據(jù)庫存儲數(shù)據(jù)，該集群通過負載均衡系統(tǒng)統(tǒng)一調(diào)度，用來存儲云存儲端的所有數(shù)據(jù)的元數(shù)據(jù)；負載均衡系統(tǒng)用來統(tǒng)一調(diào)度用戶請求，將用戶請求調(diào)配到對應的服務器上；Cache存儲服務器用來緩存HDFS中的數(shù)據(jù)，加速響應用戶請求，為用戶請求提供更快的讀寫效率；分布式存儲HDFS是分布式文件系統(tǒng)，用來備份數(shù)據(jù)，保證數(shù)據(jù)的多副本備份，提高數(shù)據(jù)安全性，并用來集中管理海量的數(shù)據(jù)文件，為系統(tǒng)功能的實現(xiàn)提供有力的數(shù)據(jù)資源保障。

1.2 元數(shù)據(jù)存儲方案設計

用戶上傳數(shù)據(jù)到云存儲服務器，云存儲服務器就要保證用戶可以隨時從云存儲服務器讀取數(shù)據(jù)，元數(shù)據(jù)就起到了這個作用。它需要保存用戶數(shù)據(jù)在云存儲服務器中的位置，通過這個位置可以讀取對應的數(shù)據(jù)，元數(shù)據(jù)的設計如圖2所示。該元數(shù)據(jù)存儲方案涉及到兩個元數(shù)據(jù)的存儲，用戶元數(shù)據(jù)以及云存儲端元數(shù)據(jù)，都以集群的形式存儲。

圖2 元數(shù)據(jù)存儲設計

MySQL-View Cluster是用來保存用戶數(shù)據(jù)元數(shù)據(jù)的一個MySQL集群，它將用戶數(shù)據(jù)的眾多屬性保存在MySQL數(shù)據(jù)庫中。為了保證系統(tǒng)的高可擴展性，MySQL以集群的形式存在。在該數(shù)據(jù)庫中，有兩個主要的字段跟用戶數(shù)據(jù)的秒傳功能實現(xiàn)有著重要的聯(lián)系，即用戶上傳的文件名file_name、用戶數(shù)據(jù)在云存儲服務器中的唯一標識符id_symbol。用戶請求自己的文件file_name時，系統(tǒng)就將id_symbol轉(zhuǎn)換為file_path，file_path就可將所指的文件返回給用戶。

MySQL-Metadata Cluster是用來存儲HDFS中的每個文件信息的數(shù)據(jù)庫集群。同樣使用MySQL集群的形式，也是為了系統(tǒng)的高可擴展性，在該數(shù)據(jù)庫中有三個主要的字段，即數(shù)據(jù)在云存儲服務器中的唯一標識符id_symbol、云存儲服務器中的真實路徑file_path、文件被引用的次數(shù)referenced_count。這個數(shù)據(jù)庫會記錄每個文件被所有的用戶引用的次數(shù)，以模擬被多個用戶使用。

MySQL-Metadata Cluster中的id_symbol和file _path字段都是系統(tǒng)中數(shù)據(jù)的唯一存在。id_symbol被設計為MySQL-View Cluster中數(shù)據(jù)庫的外碼，是兩個數(shù)據(jù)庫集群的聯(lián)系所在。

1.3 文件上傳方案設計

FSTS系統(tǒng)的優(yōu)勢就在于可以將對應的用戶數(shù)據(jù)極速地上傳到云存儲服務器上，并且相同的文件在云存儲服務器端只有一份，大大節(jié)省了云存儲服務器的存儲空間。文件上傳流程的設計如圖3所示。從圖3可以知道，如果一個文件已經(jīng)存在于云存儲服務器上，那么這個文件將可以瞬間完成上傳功能。并且云存儲服務器只需要增加一個MySQL-Metadata Cluster中的一個引用計數(shù)就可以了，無需重復讀寫數(shù)據(jù)。

文件上傳的步驟設計為：

(2) 服務器從MySQL-Metadata Cluster中查找該標識符；如果找到，則轉(zhuǎn)(3)，否則，轉(zhuǎn)(4)；

(3) 將MySQL-Metadata Cluster中對應記錄的引用計數(shù)加1，轉(zhuǎn)(9)；

(4) 負載均衡服務器找到該文件應該上傳至的Cache服務器信息，將該Cache服務器的信息返回給用戶；

(5) 用戶與對應的Cache服務器建立連接，請求將文件上傳至該服務器上；

(6) 文件傳輸過程，將用戶數(shù)據(jù)完整的上傳到對應的Cache服務器；

(7) 將Cache服務器上的用戶數(shù)據(jù)持久化上傳到HDFS上，以保證數(shù)據(jù)安全；

(8) 將用戶數(shù)據(jù)的元數(shù)據(jù)記錄至MySQL-Metadata Cluster；

(9) 將用戶數(shù)據(jù)的元數(shù)據(jù)記錄至MySQL-View Cluster；

(10) 用戶數(shù)據(jù)秒傳成功。

從上傳流程上可以看出，只要用戶上傳的數(shù)據(jù)文件已經(jīng)存在于云存儲服務器端，那么用戶數(shù)據(jù)就可以瞬間完成上傳任務。只有該文件不存在于云存儲服務器端時，才需要經(jīng)過網(wǎng)絡傳輸將數(shù)據(jù)逐漸地上傳至云存儲服務器端。

圖3 文件上傳流程設計

1.4 文件下載方案設計

FSTS的最大優(yōu)勢在于將數(shù)據(jù)快速上傳，對于數(shù)據(jù)下載并沒有太大的優(yōu)勢，但是，F(xiàn)STS系統(tǒng)并不會因此就增加數(shù)據(jù)下載的負擔。實際上，由于數(shù)據(jù)在云存儲服務器上沒有重復的存在，所以減輕了云存儲服務器上數(shù)據(jù)存儲負擔，可以在一定程度上加快數(shù)據(jù)的傳輸速度。文件下載方案的設計如圖4所示。

圖4 文件下載流程設計

文件下載的步驟設計如下：

(1) 客戶端發(fā)起文件下載請求；

(2) 負載均衡服務器找到對應的Cache服務器；

(3) 判斷文件是否存在于該Cache服務器，如果存在，則轉(zhuǎn)(7)，如果不存在，則轉(zhuǎn)(4)；

(4) 查找View Cluster元數(shù)據(jù)服務器，從而找到對應的id_symbol；

(5) 根據(jù)id_symbol，查找Metadata Cluster，找到對應的file_path；

(6) 根據(jù)file_path從HDFS中將數(shù)據(jù)copy到該Cache服務器；

(7) 返回給客戶端該Cache服務器信息；

(8) 客戶端從Cache讀取需要的文件；

(9) 文件下載完成。

從文件下載流程看，文件下載需要按照用戶請求，逐步地完成數(shù)據(jù)傳輸，并沒有什么有效的方法可以大大減少下載時間。但是，由于Cache服務器的存在，用戶比直接從HDFS讀取數(shù)據(jù)要快很多，在一定程度上提高了用戶讀取數(shù)據(jù)的速度。

1.5 文件刪除方案設計

圖5 文件刪除流程設計

文件刪除發(fā)生在用戶不想在云存儲服務器上保存自己的數(shù)據(jù)時，為了及時地響應用戶請求，本文將數(shù)據(jù)刪除設計為邏輯刪除，即只需要在用戶數(shù)據(jù)記錄上標記為已刪除即可，并不會實際刪除數(shù)據(jù)元數(shù)據(jù)記錄以及實際存儲在服務器上的數(shù)據(jù)。實際的刪除操作由系統(tǒng)后臺進程執(zhí)行，對用戶透明。文件刪除流程的設計如圖5所示。從圖5可以看出，刪除流程相當簡單，相應的操作都效率極高，可以說，用戶在瞬間即可完成刪除操作，不需要任何等待。

文件刪除流程步驟設計如下：

(1) 客戶端發(fā)起文件刪除的請求；

(2) 服務器將View Cluster中對應的記錄標記為已刪除；

(3) 服務器將Metadata Cluster中對應的記錄的引用計數(shù)減少1；

(4) 對客戶端來說，文件刪除成功。

從文件的刪除流程可以看出，服務器并沒有做任何刪除操作，只是將相應的記錄標記為已刪除和減少引用計數(shù)。

1.6 文件清理方案設計

本文將用戶的數(shù)據(jù)刪除方案設計為了邏輯刪除，即實際的數(shù)據(jù)元數(shù)據(jù)和實際的數(shù)據(jù)并沒有從服務器刪除。對系統(tǒng)而言，有些數(shù)據(jù)已經(jīng)沒有任何必要存儲在服務器上，如已經(jīng)被標記為已刪除的記錄。當系統(tǒng)容量達到一定程度時，我們就需要清理系統(tǒng)，以便可以響應其他的用戶請求，即還需要清理長久沒有使用并且沒人占用的數(shù)據(jù)，以給系統(tǒng)騰出足夠的空間。文件清理方案設計如圖6所示。

從圖6可以看出，已經(jīng)被標記為已刪除的記錄一定會被物理刪除。引用計數(shù)0的記錄，只有在最近一段時間未被訪問并且系統(tǒng)空間不足時，才會被物理刪除。這種設計方案可以在不損耗系統(tǒng)秒傳性能的前提下完成系統(tǒng)節(jié)省空間的功能。

圖6 文件清理方案設計

文件清理方案流程步驟設計如下：

(1) 周期性的啟動后臺清理程序；

(2) 遍歷View Cluster數(shù)據(jù)庫中被標記為已刪除的記錄；

(3) 清理對應的緩存文件；

(4) 刪除對應的記錄；

(5) 遍歷Metadata Cluster數(shù)據(jù)庫中引用計數(shù)為0的記錄；

(6) 如果該記錄對應的文件最近訪問時間大于N，并且系統(tǒng)的存儲空間被使用的比例大于M，則刪除文件，否則，不做物理刪除操作；

(7) 結(jié)束。

從文件清理的步驟設計上看，只有文件的引用計數(shù)為0，并且最近一段時間N時間內(nèi)沒有被訪問過，才有資格被物理刪除。為了保證云存儲空間中數(shù)據(jù)的多樣性，只有當物理空間被使用的比例大于M時，才會實際刪除物理文件，否則，不做物理刪除。

這樣設計物理文件的刪除是因為被用戶刪除的文件，在View Cluster中的記錄已經(jīng)沒有任何價值，所以直接物理刪除；在Metadata Cluster中的記錄如果引用計數(shù)不為0，則表示有用戶在使用該文件，不能刪除；當引用計數(shù)為0時，如果最近一段時間被訪問過，那么表示在將來還有可能被訪問，為了實現(xiàn)用戶更多的秒傳，該文件繼續(xù)保留在系統(tǒng)中；如果云存儲系統(tǒng)被使用的比例比較低，則該文件也繼續(xù)保留在系統(tǒng)中，因為刪除該文件只能讓系統(tǒng)的利用率更加低下，留著該文件，還有可能為以后用戶上傳文件提供高效的秒傳功能。

2 實驗與分析

為了驗證本文設計的秒傳系統(tǒng)的可用性與高效性，本實驗在開啟秒傳與關(guān)閉秒傳功能的前提下，分別統(tǒng)計上傳、下載、刪除等操作的操作時間以及系統(tǒng)中元數(shù)據(jù)記錄情況。

2.1 實驗設計

本實驗模擬三個用戶分別對同一個文件進行操作，讓云存儲服務器上的數(shù)據(jù)經(jīng)歷從無到有，在無數(shù)據(jù)以及有數(shù)據(jù)的情況下，統(tǒng)計各自的操作時間。

2.1.1 實驗環(huán)境

為了簡化實驗環(huán)境，但盡可能模擬真實的應用環(huán)境，本實驗搭建了HDFS集群，并部署了兩臺Cache服務器，搭建了兩個MySQL集群，分別用來模擬MySQL-Metadata Cluster以及MySQL-View Cluster。在同臺設備上，通過修改客戶端ID，先后啟動多次客戶端，用來模擬三個客戶，進行不同的文件操作。

2.1.2 實驗步驟

搭建完畢實驗環(huán)境，本實驗將實驗步驟設計如下：

(1) 開啟秒傳功能；

(2) 配置客戶端ID為1,啟動客戶端；

(3) 將文件file上傳至云存儲服務器，記錄上傳時間；

(4) 從云存儲服務器下載該文件，記錄下載時間；

(5) 將文件從云存儲服務器刪除，記錄刪除時間；

(6) 查看服務器上的文件數(shù)目，并連同上述記錄的時間一起填入表1的第一行記錄中；

(7) 配置客戶端ID為2，啟動客戶端；

(8) 重復執(zhí)行步驟(2)-步驟(4)；

(9) 將記錄的時間填入表1的第二行記錄中；

(10) 配置客戶端ID為3，啟動客戶端；

(11) 將文件重命名；

(12) 重復執(zhí)行步驟(3)-步驟(5)；

(13) 將記錄的時間填入表1的第三行記錄中；

(14) 關(guān)閉秒傳功能；

(15) 重復執(zhí)行步驟(2)-步驟(13)，只是將所有的數(shù)據(jù)記錄在表2中，而不是表1中。

2.2 實驗結(jié)果與分析

執(zhí)行上述實驗步驟，得到的實驗數(shù)據(jù)如表1和表2所示。其中，在每個表中，記錄1是客戶端1的操作時間記錄，記錄2是客戶端2的操作時間記錄，記錄3是客戶端3的操作時間記錄。

表1 開啟秒傳功能時操作時間記錄(單位：min)

表2 關(guān)閉秒傳功能時操作時間記錄(單位：min)

從表1可以看出，記錄1的上傳時間為39 min，而記錄2和記錄3的上傳時間只有2 min，記錄1的上傳時間遠遠大于記錄2和記錄3的上傳時間；記錄1和記錄2、記錄3的文件下載時間分別為33、36和34 min，時間大小差距不大，可以認為是效率相當；記錄1、記錄2和記錄3的文件刪除時間都小于1 min，刪除效率都差不多，效率都很高。

表1中，記錄1的上傳時間遠大于記錄2的上傳時間，是因為客戶端1在上傳文件時，該文件在服務器中并沒有相同的文件存在，數(shù)據(jù)必須逐漸地上傳至服務器上；而記錄2時間很短是因為客戶端1上傳的文件在服務器上還沒有被物理刪除，對應的Metadata Cluster中還有記錄存在，所以客戶端的物理文件就不用再上傳至服務器端，而只需要增加Metadata Cluster中對應記錄的引用計數(shù)即可。

表1中，客戶端3操作的是重命名后的文件，它的操作時間與客戶端2的操作時間沒有較大差別，幾乎相同。這說明，單純地修改文件名，只要文件內(nèi)容相同，也是可以做到秒傳的。這與系統(tǒng)對文件判別的方式相關(guān)，本實驗采取MD5值作為文件是否唯一的標準來衡量的。雖然MD5值需要一些計算時間，但是，比起較長時間的文件傳輸，這點時間還是值得的。

從表2可以看出，三個客戶端的上傳、下載、刪除數(shù)據(jù)時間幾乎是相同的。并且，其服務器上的文件數(shù)目每上傳一次都會增加1，導致云存儲服務器上大量的重復數(shù)據(jù)存在。

由表1和表2可知，本文設計的云存儲環(huán)境下的文件秒傳系統(tǒng)是可行的。對于服務器端已經(jīng)存在的文件，它可以完成快速的上傳功能，并且不影響用戶對數(shù)據(jù)文件的其他操作。這種設計可以避免服務器端的文件重復存儲，大大減輕了服務器的存儲壓力。

3 結(jié) 語

云計算的發(fā)展帶動了云存儲的快速發(fā)展，使得云存儲在越來越多的領(lǐng)域得到應用。云存儲為越來越多為人所熟知，并且為越來越多的互聯(lián)網(wǎng)用戶所使用。但是，云存儲環(huán)境是基于互聯(lián)網(wǎng)而存在的，離不開網(wǎng)絡的支持，網(wǎng)絡有自身的限制，數(shù)據(jù)的傳輸速度受限于很多因素，如網(wǎng)絡帶寬、網(wǎng)絡當時的擁擠程度等。而用戶一般都想讓自己的數(shù)據(jù)快速地上傳至云存儲服務器以完成數(shù)據(jù)的備份。用戶的需求使得云存儲提速顯得格外重要。本文設計的文件秒傳系統(tǒng)可以在很大程度上滿足用戶的需求，該系統(tǒng)基于云存儲服務器端豐富的數(shù)據(jù)資源，建立元數(shù)據(jù)資源庫，為用戶的上傳數(shù)據(jù)服務額外的對比功能，使得已經(jīng)存在的文件不再上傳至服務器，而是增加引用計數(shù)，使得多用戶共享同一個文件。這種設計方案不但可以大大加速用戶上傳文件的平均速度，而且可以節(jié)省云存儲服務器的存儲空間。下一步就是對如何判別同一個文件的條件做深入研究，使秒傳系統(tǒng)以更快更好的效率服務于用戶。

[1] Luo Y,Luo S,Guan J,et al.A RAMCloud Storage System based on HDFS:Architecture,implementation and evaluation[J].Journal of Systems and Software,2013,86(3):744-750.

[2] 劉淵,楊澤林.基于模擬信息轉(zhuǎn)換器的物聯(lián)網(wǎng)海量數(shù)據(jù)處理研究[J].計算機應用研究,2013,30(12):3694-3697.

[3] Wang C,Chow S S M,Wang Q,et al.Privacy-preserving public auditing for secure cloud storage[J].Computers,IEEE Transactions on,2013,62(2):362-375.

[4] 張桂剛,李超,張勇.一種基于海量信息處理的云存儲模型研究[J].計算機研究與發(fā)展,2012,49(7):32-36.

[5] 覃雄派,王會舉,杜小勇.大數(shù)據(jù)分析-RDBMS與MapReduce的競爭與共生[J].軟件學報,2012,23(1):32-45.

[6] 張鴻輝,劉偉,李永強.應用于電網(wǎng)企業(yè)的云存儲訪問控制增強策略[J].計算機應用與軟件,2014,31(2):17-20.

[7] Zeng W,Zhao Y,Ou K,et al.Research on cloud storage architecture and key technologies[C]//Proceedings of the 2nd International Conference on Interaction Sciences: Information Technology,Culture and Human.ACM,2009:1044-1048.

[8] 周江,王偉平,孟丹.面向大數(shù)據(jù)分析的分布式文件系統(tǒng)關(guān)鍵技術(shù)[J].計算機研究與發(fā)展,2014,51(2):382-394.

[9] Yang K,Jia X,Ren K.Attribute-based fine-grained access control with efficient revocation in cloud storage systems[C]//Proceedings of the 8th ACM SIGSAC symposium on Information, computer and communications security.ACM,2013:523-528.

[10] Iacono L L,Torkian D.A System-Oriented Approach to Full-Text Search on Encrypted Cloud Storage[C]//Cloud and Service Computing (CSC),2013 International Conference on.IEEE,2013:24-29.

[11] 翟巖龍,羅壯,楊凱,等.基于Hadoop的高性能海量數(shù)據(jù)處理平臺研究[J].計算機科學,2013,40(3):100-103.

DESIGN AND IMPLEMENTATION OF FILE SECOND TRANSMISSION SYSTEM IN CLOUD STORAGE ENVIRONMENT

Hu Yuping

(ChongqingWaterResourcesandElectricEngineeringCollege,Chongqing402160,China)

To solve the problem of slow speed in uploading user’s data to server in cloud storage environment, this paper designs a file second transmission system. The system sets up the metadata resource library based on sufficient data resource in cloud storage servers, and implements data second transmission by designing the files to a mode of resource sharing. The metadata resource library organises the data in cloud storage server by the unique field which marks the content of data so as to ensure in the resource library there are no duplicate data. When user upload data to cloud storage server, if the unique identity of this data can be found in metadata resource system, then the system can complete user’s upload operations by just increasing the reference count of the record, but not transmitting any data through internet. That is to say, it implements the logical files upload, and ensures that the following operations on the data are all normal. Experimental result indicates that the file second transmission system designed in the paper can improve the data upload speed well, and can improve the use ratio of cloud storage server space, the scheme is feasible and effective in cloud storage environment.

File second transmission Cloud storage Metadata Reference count

2014-09-30。胡渝蘋，講師，主研領(lǐng)域：計算機軟件應用，計算機教育。

TP311

A

10.3969/j.issn.1000-386x.2016.04.076

(1) 用戶發(fā)起文件上傳的請求；請求數(shù)據(jù)中包括

符等一些系統(tǒng)需要的信息；