文件秒傳系統在云存儲環境下的設計與實現

胡 渝 蘋

文件秒傳系統在云存儲環境下的設計與實現

胡 渝 蘋

(重慶水利電力職業技術學院 重慶 402160)

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

文件秒傳 云存儲 元數據 引用計數

0 引 言

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

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

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

1 FSTS的設計與實現

FSTS是本文設計的一種實現文件秒傳功能的系統，這種系統可以讓用戶在極短的時間內完成數據上傳的功能。這種系統的實現需要有海量的數據為基礎，這些數據將用來作為用戶的數據備用庫。

本文設計的FSTS是基于云存儲的大數據而存在的，它依賴于云存儲環境，并且該系統的效率與云存儲的數據存在有很大的關系。用戶上傳數據的操作能否在極短的時間內完成，取決于該數據在云存儲系統中是否存在。

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

1.1 總體架構設計

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

圖1 FSTS總體架構設計

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

1.2 元數據存儲方案設計

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

圖2 元數據存儲設計

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

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

MySQL-Metadata Cluster中的id_symbol和file _path字段都是系統中數據的唯一存在。id_symbol被設計為MySQL-View Cluster中數據庫的外碼，是兩個數據庫集群的聯系所在。

1.3 文件上傳方案設計

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

文件上傳的步驟設計為：

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

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

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

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

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

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

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

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

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

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

圖3 文件上傳流程設計

1.4 文件下載方案設計

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

圖4 文件下載流程設計

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

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

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

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

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

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

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

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

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

(9) 文件下載完成。

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

1.5 文件刪除方案設計

圖5 文件刪除流程設計

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

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

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

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

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

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

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

1.6 文件清理方案設計

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

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

圖6 文件清理方案設計

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

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

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

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

(4) 刪除對應的記錄；

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

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

(7) 結束。

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

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

2 實驗與分析

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

2.1 實驗設計

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

2.1.1 實驗環境

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

2.1.2 實驗步驟

搭建完畢實驗環境，本實驗將實驗步驟設計如下：

(1) 開啟秒傳功能；

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

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

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

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

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

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

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

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

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

(11) 將文件重命名；

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

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

(14) 關閉秒傳功能；

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

2.2 實驗結果與分析

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

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

表2 關閉秒傳功能時操作時間記錄(單位：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在上傳文件時，該文件在服務器中并沒有相同的文件存在，數據必須逐漸地上傳至服務器上；而記錄2時間很短是因為客戶端1上傳的文件在服務器上還沒有被物理刪除，對應的Metadata Cluster中還有記錄存在，所以客戶端的物理文件就不用再上傳至服務器端，而只需要增加Metadata Cluster中對應記錄的引用計數即可。

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

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

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

3 結 語

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

[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] 劉淵,楊澤林.基于模擬信息轉換器的物聯網海量數據處理研究[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].計算機研究與發展,2012,49(7):32-36.

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

[6] 張鴻輝,劉偉,李永強.應用于電網企業的云存儲訪問控制增強策略[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] 周江,王偉平,孟丹.面向大數據分析的分布式文件系統關鍵技術[J].計算機研究與發展,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的高性能海量數據處理平臺研究[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。胡渝蘋，講師，主研領域：計算機軟件應用，計算機教育。

TP311

A

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

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

符等一些系統需要的信息；