一種基于Swift云存儲組件的冗余去重方法

徐驍，夏敏，張鵬，陳潔，張照星

（1.公安部戶政管理研究中心，北京100070；2.北京大學軟件與微電子學院，北京102600）

0 引言

隨著互聯網應用的發展，每天都會產生海量的用戶數據，如何快速、高效地處理和存儲這些數據成為大數據時代的研究重點。為解決海量數據的存儲與處理的難題，云存儲技術應運而生。文獻[1-5]的研究發現：當前的主流云存儲架構中，為確保數據安全，云存儲系統會為每一個數據塊復制出多個副本，并將這些的副本分散存儲在不同的物理節點，即可確保某一節點上的數據塊失效時，集群中的其他節點仍有該數據塊的有效副本，從而保證數據安全。

網盤是各類云存儲技術應用中非常重要且越來越普及的一種應用形式。在網盤的使用過程中難免會出現如下場景：兩個用戶先后上傳了相同的文件；用戶將別人分享的文件轉存到自己的網盤。這時如果網盤直接使用云存儲接口，那么云存儲集群中就會存在相同的文件副本。當用戶上傳的相同文件越來越多、分享越來越多，云存儲集群中必將產生大量的冗余副本。原本用于確保數據安全的副本變成了占用大量存儲資源的累贅。不僅如此，相同文件的重復傳輸會占用大量的網絡帶寬，冗余副本在集群中負載均衡會消耗計算資源。因此在使用云存儲組件開發網盤類應用時，要對重復上傳的文件進行處理。

高校的教堂管理系統往往需要集成課件上件下載功能，因此產生重復文件的機會大大增加。針對這個問題作者在將Swift云存儲組件應用到課件管理子系統中時提出了一種對冗余文件去重的方法。

1 背景介紹

1.1 云存儲

云存儲是在云計算的概念基礎上發展出來的新興技術[6]。它將傳統的集群技術、網絡技術、分布式文件系統等技術結合起來，使分散在網絡中的存儲設備能夠協同工作，并作為一個整體對外提供統一的存儲服務[7]。

文獻[1][8]詳細論述了一種能夠適應極速增長的數據處理需求的分布式文件系統：谷歌文件系統（Google File System，GFS）。GFS通過集群中的Master節點來管理數據塊在Chunkserver節點中的分布，均衡各Chunkserver的負載，為Client節點提供最新的可用副本，并回收不再使用的存儲空間。受到文獻[1][2]的啟發，Apache基金會發布了開源的Hadoop框架，提出了Hadoop分布式文件系統（Hadoop Distributed File System，HDFS）[3]。HDFS認為每個數據塊在本地節點、同一機架的不同節點以及不同機架上的節點都應該有一個副本。2006年，亞馬遜在原云服務（Amazon Web Service，AWS）的基礎上又推出了簡單存儲服務（Sim-ple Storage Service，S3）[4]，它能夠通過 Web Service方式或RESTful API方式存取云存儲集群中的文件，便于整合到各類Web應用中[9-10]。2010年，美國國家宇航局（NASA）與Rackspace聯合發布了開源云計算平臺Openstack[5]，其中包括Swift云存儲組件。Swift一方面采用了3副本的副本管理策略，另一方面提供了與S3相兼容的RESTful API[11]。

綜上，云存儲系統中普遍使用副本冗余的技術來確保云存儲系統能夠在廉價設備上實現高可靠和高容錯。同時冗余副本的存在也帶來一些隱患包括：（1）占用更多的存儲空間；（2）各節點間的數據傳輸需要占用網絡帶寬；（3）冗余副本的負載均衡會消耗計算資源。因此在云存儲系統內部需要更優的副本管理策略來達到安全與效率的平衡，在云存儲系統外部，也應該減少潛在的冗余副本。

1.2 網盤應用

網盤應用是各類云存儲技術應用中非常重要且越來越普及的一種應用形式。筆者調研了國內比較有代表性的網盤應用，并比較了它們的功能特點。從而提出了云存儲系統在網盤應用中需要注意的問題。

百度網盤是百度于2012年推出的一項云存儲服務，通過客戶端，用戶能夠“秒傳”熱門資源。用戶能夠生成分享鏈接，也可以將別人通過百度網盤分享的資源轉存到自己的百度網盤中[12]。

騰訊微云是騰訊公司為用戶精心打造的一項智能云服務，用戶可以通過微云方便地在手機和電腦之間同步文件、推送照片和傳輸數據[13]。它與QQ、微信、郵箱等產品進行了深度整合，用戶既可以通過QQ、微信、郵箱等分享微云中的文件，也可以把別人分享的文件方便地轉存到微云中。

115網盤是廣東一一五科技有限公司于2009年推出的網絡數據在線存儲服務[14]。115的文件分享功能十分強大，用戶可以收藏和轉存別人分享的文件，可以將文件分享給指定的一個或者多個用戶（現由于公司原因關閉了分享功能）。通過PC客戶端，115網盤可以“秒傳”熱門文件，并支持文件斷點續傳[14]。

綜上可見，主流的網盤應用都會具備：1、文件的“秒傳”功能；2、文件的分享功能；3、文件的轉存功能。這些功能反映了網盤應用中，必將會保存大量的相同文件。如果這些重復的文件在云存儲組件中不加以處理，按照云存儲系統中一個數據塊有多個數據副本的管理策略，將會給云存儲系統帶來巨大的壓力。

2 需求分析與設計

2.1 課件管理子系統需求

課件管理子系統的每一個用戶有自己的“存儲空間”，用戶可以在自己的“存儲空間”里創建、修改、刪除文件，各個用戶的“存儲空間”互不干擾；教師用戶向課程中添加、刪除課程資料文件的過程，即分享文件的過程；學生用戶可以訪問并下載某一課程中的資料，也可以將資料轉存到自己的“存儲空間”。

課件管理子系統要解決由文件共享、不同用戶上傳同一文件帶來的冗余問題。當一個文件被多次共享、轉存或者上傳，云存儲組件中應該只有一份文件及其必要的副本，而不應該出現多個同樣的文件。

2.2 Swift存儲層設計

作者選用了開源的Swift云存儲組件作為課件管理子系統的存儲層，采用MySQL數據庫為課件管理子系統提供管理信息的存儲，使用PHP的Yii框架作為開發框架實現系統邏輯，最上層通過JS及HTML技術做頁面展示。

（1）Swift組件網絡設計

為確保數據的安全，作者將Swift集群部署在私網網段中，對外提供服務的Web服務器通過雙網卡，一塊與外網相連，一塊與私網相連。在Swift集群內部部署一臺代理節點服務器和若干臺數據節點服務器，它們之間通過私網的交換機相連。如圖1所示。

圖1 Swift集群網絡拓撲圖

（2）API封裝設計

Swift通過RESTful API對外提供最基礎的存儲服務，包括請求認證、創建容器、刪除容器、上傳文件、下載文件、刪除文件和復制文件。為方便應用系統內部調用Swift服務，將它們用PHP進行封裝。實現功能如表1所示。

表1 API與封裝對應關系表

（3）去重方案設計

為了避免將重復的文件上傳到Swift集群中，作者將存儲邏輯與去重邏輯分離，Swift集群只負責存儲文件。數據庫則記錄了（1）用戶與文件的持有關系；（2）存儲于Swift集群中所有文件的哈希值。在上傳文件之前，先計算出待上傳文件的哈希值，再與數據庫中現有的文件哈希值進行比較，如果此文件已經存在于Swift集群，那么系統直接生成一條用戶持有該文件的關聯記錄，不再重復上傳文件。去重流程如圖2所示。

用戶之間的文件分享關系，實際上是文件與用戶之間一種特殊的臨時的“持有”關系，用戶可以將文件轉存到自己的“存儲空間”把分享關系轉變成持有關系。當一個文件被多個用戶持有時，任何一個用戶刪除自己的文件，不會影響到其他用戶持有此文件。而一個文件被分享給其他用戶時，若持有此文件的用戶刪除文件，其他用戶也將無法訪問到被刪除的文件。為了保證安全，用戶在通過網頁查看文件的時候，系統實時生成各個文件的下載鏈接，此鏈接具有時效性，且只能供當前登錄用戶下載。

圖2 上傳文件的去重流程圖

（4）數據庫設計

根據上述分析，設計數據庫E-R圖如圖3所示。其中，對象表用于存儲Swift集群中各對象的元信息（包括對象名、對象類型、對象大小等）、哈希值以及管理信息（包括對象編號、上傳時間、上傳用戶、刪除標識等）。用戶表用于存儲用戶信息，包括用戶編號、用戶名、加密后的登錄密碼等。持有關系表存儲了用戶編號和對象編號，以及用戶對持有對象的命名（持有名）、存儲路徑（持有路徑）以及必要的管理信息。分享關系表與持有關系表類似，存儲了用戶編號、對象編號、對象哈希值以及分享的狀態信息（包括分享狀態、分享時間、分享鏈接等）。持有關系表和分享關系表中都有隨機數字段，用于判斷和校驗文件的持有狀態和分享狀態是否有效。

圖3 數據庫E-R圖

3 功能實現

3.1 存儲邏輯實現

筆者將最基礎的存儲邏輯封裝成OpenstackTool工具類，實現了請求認證、創建容器、新建目錄、上傳文件、下載文件、刪除文件、復制文件等基本功能。其中upload（）方法實現了文件上傳功能，它將Swift請求認證得到的token、對象類型、對象名作為PUT請求頭部參數，把待上傳文件作為PUT請求體，向Swift的代理節點發送PUT請求。download（）方法實現了文件下載功能，它將token、待下載對象名、對象類型、對象大小作為GET請求參數，向Swift代理節點發送GET請求，返回目標文件內容。deleteFile（）方法實現的是刪除文件功能，它把容器名、目錄名、待刪除的對象名拼接在Swift URL中，將token作為請求頭部參數，向Swift節點發送DELETE請求，如果文件刪除將返回成功，否則返回錯誤信息。copyFile（）方法實現了文件復制功能，它將目標路徑、目標對象名拼接到Swift URL之后，把token、源對象、對象大?。◤椭撇僮鲿r，對象大小設置為0）作為PUT請求頭部參數，向Swift代理節點發送PUT請求。

3.2 去重方法實現

由于去重的邏輯滲透于課件管理子系統的文件上傳、文件分享、文件轉存、文件刪除等環節中，因此作者通過三個類中的四個方法來實現去重邏輯。首先是UploadController類中的actionUpload（）方法，實現了上傳中檢測重復文件、遇重復文件秒傳的去重邏輯。它先將待上傳文件的哈希值作為查詢條件，到數據庫中查詢該文件是否為重復文件。若是，則向數據庫持有關系表中添加一條新記錄，將原對象與當前用戶相關聯，并把對象的持有計數加1；若否，則在對象表中插入一個新對象記錄，再向持有關系表插入新持有記錄，最后調用OpenstackTool工具類中的upload（）方法將文件上傳到Swift集群。其次是ShareController類中的actionShare（）方法，實現了向指定用戶分享文件時的去重邏輯。它會為每一個分享目標用戶在分享關系表中新建一條分享記錄，再更新持有此文件的用戶的持有記錄，將共享狀態設置成已共享的狀態。此信息只有分享者有權限修改或者刪除。actionSave（）方法，實現了用戶轉存共享文件時的去重邏輯。它根據分享信息，為用戶生成一條持有信息，并將相應對象的持有計數加1。這樣，即使原用戶刪除或者停止共享該文件對象，當前用戶也依舊持有該文件。最后是NetDiskTool工具類中的deleteSingleFile（）方法，實現了刪除文件時的去重邏輯。由于Swift集群中只保存了一份文件及其相應副本，deleteSingleFile（）方法在刪除文件前，會判斷它的持有計數，如果計數大于1，則說明還有別的用戶持有此文件，此時僅刪除與此用戶相關的持有記錄，并將該對象的持有計數減1。如果計數小于等于1，說明此用戶是持有該對象的最后一個用戶，此時不僅要刪除該用戶的持有記錄，還要刪除Swift集群中存儲的對象和對象表中的對象記錄。

4 實驗及測試

筆者首先對Swift集群進行了測試，以確保存儲層可以正常工作并能夠通過RESTful API對外提供服務。然后對課件管理子系統進行測試，重點測試與去重策略相關的若干功能。

4.1 Swift組件的部署及測試

Swift集群部署在4臺PC服務器上，其中一臺部署為Swift代理節點，三臺部署為Swift存儲節點。4臺服務器均處于私網環境，需要遠程登錄到Web服務器上才能對其進行測試。

筆者首先使用Swift提供的命令行工具對Swift集群的可用性進行測試。使用“swift upload”命令上傳測試文件，然后使用“swift list”命令查看已上傳的文件。如圖4所示。

圖4 Swift基礎功能測試

使用curl命令，向Swift發送GET請求，下載剛才的測試文件，并另存為downloaded-test.txt。如圖5所示。

圖5 Swift API測試

通過測試，說明Swift集群搭建完成，并且可能通過RESRful API對外提供服務。

4.2 課件管理子系統的部署及測試

課件管理子系統部署在Web服務器上，此服務器通過雙網卡來實現內外網的聯通。首先測試通過外網訪問課件管理子系統，然后測試系統是否可以調用Swift接口來存儲文件。如圖6圖7圖8所示。

圖6 課件管理子系統上傳結果

通過測試，說明課件管理子系統不僅能夠從外網訪問，還可以調用私網的Swift存儲服務。

4.3 去重方法的測試

將4.2中的測試文件改名后，使用課件管理子系統再次上傳同一文件，然后通過“swift list”命令查看Swift集群中保存了幾份文件，通過SQL語句查詢對象表中的記錄數和持有關系表的記錄數。如圖9圖10所示。

圖7 上傳后對象表記錄情況

圖8 上傳后持有表記錄情況

圖9 上傳重復文件后對象表記錄情況

圖10 上傳重復文件后持有關系表記錄情況

然后使用分享和轉存功能，將此文件分享給用戶B，用戶B將文件轉存到自己的目錄。分別通過“swift list”命令和SQL語句，查詢Swift集群中的文件數以及對象表中的記錄、持有關系表的記錄、分享關系表的記錄。如圖11圖12圖13圖14所示。

圖11 分享文件后分享關系表記錄情況

圖12 轉存文件后對象表記錄情況

圖13 轉存文件后持有關系表記錄情況

圖14 Swift中各對象情況

通過測試，筆者提出的去重策略有效地避免了Swift集群中出現冗余文件，減少了Swift集群的壓力，達到了預期的效果。

5 結語

筆者發現當前主流的云存儲組件對重復上傳的文件不進行任何處理，如果直接應用于網盤應用的開發，將會產生大量的重復文件，占用存儲資源、消耗網絡帶寬、影響用戶體驗。于是作者基于Swift云存儲組件，使用PHP的開發框架，設計并實現了一個針對文件冗余的去重方法。該方法在文件上傳云之前進行重復文件的判斷，通過業務邏輯實現對Swift集群中已有的文件進行共享和轉存操作，從源頭上消除了產生冗余的可能。但是當前判斷重復文件的工作仍在服務器端進行，仍會消耗網絡帶寬。下一步，應開發相應的客戶端，將判斷重復文件的工作轉移到客戶端，以減少帶寬的消耗，從而更好地改善用戶體驗。

[1]Ghemawat S,Gobioff H,Leung S T.The Google File System[C].Nineteenth ACM Symposium on Operating Systems Principles.ACM,2003:29-43.

[2]Dean J,Ghemawat S.MapReduce:Simplified Data Processing on Large Clusters[C].Conference on Symposium on Opearting Systems Design&Implementation.USENIX Association,2008:10-10.

[3]Shvachko K,Kuang H,Radia S,et al.The Hadoop Distributed File System[C].MASS Storage Systems and Technologies.IEEE,2010:1-10.

[4]Amazon Web Services,Inc.Amazon Simple Storage Service文檔[EB/OL].https://aws.amazon.com/cn/documentation/s3/,2017-11-10.

[5]The OpenStack Foundation.OpenStack Documentation[EB/OL].https://docs.openstack.org/pike/,2017-11-10.

[6]李邐.淺析云計算背景下云存儲的優勢與劣勢[J].計算機光盤軟件與應用,2013（23）:18-19.

[7]百度百科.云存儲[EB/OL].https://baike.baidu.com/item/云存儲,2017-11-10.

[8]Geek_Ma.Google文件系統（GFS）翻譯學習[EB/OL].http://www.cnblogs.com/geekma/archive/2013/06/09/3128372.html,2017-10-12.

[9]Prabhakar Chaganti.用Amazon Simple Storage Service（S3）在云中存儲數據[EB/OL].https://www.ibm.com/developerworks/cn/web/ar-cloudaws2/,2017-11-10

[10]Andrew Glover.使用Amazon S3云服務輕松實現存儲[EB/OL].https://www.ibm.com/developerworks/cn/java/j-s3/,2017-11-10.

[11]The OpenStack Foundation.OpenStack Wiki[EB/OL].https://wiki.openstack.org/wiki,2017-11-10.

[12]百度.百度網盤幫助中心[EB/OL].https://yun.baidu.com/disk/help,2017-11-10.

[13]騰訊.騰訊微云[EB/OL].https://www.weiyun.com/,2017-11-10.

[14]115科技.115幫助中心[EB/OL].http://115.com/115501,2017-11-10.