一種支持數據去冗和擴容的多媒體文件云存儲系統實現

汪 帥 呂江花 汪溁鶴 吳繼芳 馬世龍

1(中國空間技術研究院 北京 100086) 2(北京航空航天大學計算機學院 北京 100191) (buaashuai@buaa.edu.cn)

互聯網的高速發展產生了海量數據，導致海量數據的傳輸和存儲場景日益增多，在這種背景下數據存儲技術得到了快速發展[1-3].過去10多年在多個應用領域產生的多媒體文件數量增長非常迅速，多媒體文件在互聯網信息中占有很大比重，所以海量多媒體文件存儲技術是一個重要研究課題[4-5]，分布式文件系統成為了當今的研究熱點.目前，在分布式文件系統中存儲海量多媒體文件時，還普遍存在著存儲性能不高、存儲空間利用率低、性能瓶頸及單點故障等問題，因此，如何解決海量多媒體文件在存儲和傳輸過程中存在的諸多實際問題，是當前計算機存儲技術研究領域非常重要的工作[6].

隨著云計算技術的廣泛應用，越來越多的應用程序為用戶提供圖片、視頻、音頻等多媒體文件的存儲和查詢服務，這類型文件通常具有存儲周期長、轉載復制頻繁、文件內容不宜分割等特點[7]，運用分布式存儲雖然可以提高多媒體文件的訪問效率，避免網絡傳輸瓶頸對多媒體文件造成的訪問延遲和磁盤存儲空間瓶頸對多媒體文件存儲造成的吞吐性能下降.但是，很多應用程序向用戶提供的多媒體文件上傳入口會使云存儲平臺積累大量重復的多媒體文件，這樣既給應用程序開發商增加了存儲成本，也降低了多媒體文件的訪問效率[8].因此，為了滿足這類應用程序對多媒體文件存儲和管理的需求，對多媒體文件進行分布式存儲、刪除重復的多媒體文件、保護用戶隱私、支持對存儲目錄動態邏輯擴容，對于提高系統性能、降低存儲成本、提升用戶體驗具有重要意義.

本文提出一種分布式存儲目錄動態建模方案，用來描述整個數據中心的存儲目錄邏輯結構，應用程序基于此模型可以方便地管理用戶上傳的多媒體文件，簡化存儲文件和獲取文件的過程.基于此建模方案實現的多媒體文件云存儲系統，支持對指定存儲目錄中的多媒體文件進行數據去冗，并且該系統可以在運行過程中對存儲目錄進行動態邏輯擴容.應用程序可以自定義存儲目錄樹的邏輯結構，應用程序通過該云存儲系統保存文件時，不必擔心某個存儲目錄的磁盤占用空間已達到存儲上限的問題，該云存儲系統解決了數據冗余度高的應用程序在低存儲成本條件下對多媒體文件進行分布式存儲的問題.

1 相關工作

云計算的發展使越來越多的信息被數據化，大量數據密集型的應用程序每天產生的體積較小的多媒體文件呈幾何級增長[9].Facebook這類大型社交軟件每周產生的圖片數據高達60TB[10]，淘寶網的圖片存儲量已經達到2PB[11]，如何對海量多媒體小文件進行有效的存儲與管理，減輕應用程序的負擔，已是存儲領域必須要面對的一個重要課題.

Ross等人[12]提出的PVFS(parallel virtual file system)是一個高性能、可擴展的分布式并行文件系統，PVFS將文件分散到多個存儲結點的多塊磁盤上，實現了對文件的條帶化存儲，消除了單個存儲結點引發的瓶頸問題，但是它缺乏必要的容錯機制并且配置不夠靈活，適用于對文本文件進行并行訪問和分析.Lustre文件系統[13]是基于對象存儲的大規模分布式文件系統，它把數據劃分成條帶存儲在多個對象存儲服務器(object storage server, OSS)上，當某個OSS發生故障時仍能保證存儲在該服務器上的數據不丟失.它是基于Linux內核級的分布式文件系統，多數用于高性能計算中.Lustre文件系統不支持數據去冗，同時數據的條帶化導致它在小文件存取時表現較差，每次讀取小文件都需要從多個存儲服務器結點上獲取文件的每個數據塊，然后把這些數據塊拼接成一個完整的小文件返回給應用程序.

Google文件系統(Google file system, GFS)[14]是一個支持數據密集型應用的、高度容錯且具有高吞吐量的分布式文件系統，GFS支持多個客戶端并行的對同一個文件進行內容追加操作，同時它能夠保證每個客戶端在在給同一個文件內容進行追加操作時的原子性，GFS會把文件切分成相同大小的數據塊存儲在不同的數據結點.對于多媒體文件來說，如果把它的內容切分成不同的數據塊分布式存儲，那么在訪問這些多媒體文件內容時，就需要從多個數據結點把數據塊全部取到然后返回給應用程序，這樣會額外消耗很多資源，而且GFS不支持通過HTTP協議訪問多媒體文件.基于GFS的設計思想，Konstantin等人[15]實現了開源的HDFS(Hadoop distributed file system)，HDFS也不支持通過HTTP協議訪問多媒體文件，HDFS的命名空間結點把系統中所有的元數據都放置在內存中，如果系統中存在海量的體積比較小的多媒體文件，會降低整個存儲系統的存儲效率和存儲能力.

淘寶文件系統(Taobao file system, TFS)[16]是一個構建在普通的Linux機器集群上的、對外提供高可靠和高并發訪問的分布式文件系統.TFS為阿里巴巴提供海量小文件存儲，滿足了阿里巴巴對小文件存儲的需求，被廣泛地應用在阿里巴巴各項應用中.TFS采用扁平化的數據組織結構，一方面它把多個小文件壓縮在一個數據塊中進行存儲，另一方面它把文件名映射到文件的物理地址，簡化了文件的訪問流程，一定程度上為TFS提供了良好的讀寫性能.當TFS客戶端需要讀取文件內容時，它將文件名轉換為文件塊號和文件號，然后在命名空間結點上取得文件塊號所對應的數據結點信息，之后客戶端通過數據結點獲取數據塊內容，然后根據文件號找到文件的具體內容.TFS不支持數據去冗，它把圖片編號作為元數據存儲在外部數據庫中，TFS對數據庫比較依賴而且要求數據庫具有很高的性能，每次獲取圖片信息時都要進行讀取數據庫操作，然后去確定圖片的存儲位置.

表1直觀地顯示了上述4個文件系統之間的差異和不足:

Table 1 Different Feature of File Systems表1 文件系統對比

① Large: File size greater than 10 MB.

② Small: File size less than 10 MB.

在具備擴展性的高性能文件系統研究方面，OceanStore[17]和Farsite[18]可以提供TB級別的高可靠文件存儲，同時支持幾千個客戶端并發訪問文件內容，但是它們由于命名空間結點的瓶頸，不能支持客戶端高并發訪問小文件.Ceph[19]是一個擴展性較強的高性能分布式文件系統，Ceph文件系統為異構的并且擁有不可靠對象存儲設備的動態集群設計了偽隨機數據分發函數，通過替換分配表來最大化分離數據和元數據管理之間的耦合關系，但是它在安全性和POSIX調用[20]方面還有待進一步完善.Chung等人[21]提出的分布式文件系統雖然可以降低存儲成本并且擁有不錯的性能，但它在擴展性方面表現較差.Hao等人[22]提出的鏈接分布式文件系統支持對文件進行多版本管理，但擴展性和實用性較差.Xiong等人[23]、Cao等人[24]和Chao等人[25]在實用性方面各自研究了分布式存儲策略，但他們的研究方向偏向于文件副本策略.在小文件管理方面，Dong等人[26-27]、Chandrasekar等人[28]和Chatuporn等人[29]在HDFS的基礎上優化了小文件的存儲策略，一定程度上提高了HDFS在小文件存儲和訪問方面的性能，但他們對多媒體文件去冗方面研究較少.

在多媒體文件數據去冗領域，根據去冗粒度的不同，去冗方式可以分為字節級的去冗、數據塊級的去冗和文件級的去冗，不同的去冗方式各有利弊.1)對于字節級去冗，一般在字節層面查找和刪除重復的數據，通常使用差異壓縮策略生成差異部分內容，它的優點是去冗率很高，缺點是去冗的速度比較慢，不適合對數據實時去冗.2)數據塊級的去冗方式將文件按一定的策略劃分成多個數據塊，把數據塊視為去冗的基本單位，它的優勢是計算速度較快，去重效率也較高，但對數據變化比較敏感.3)文件級的去冗方式把整個文件當作檢測和去冗的基本單位，首先計算整個文件的指紋，然后根據文件指紋在存儲系統中查找是否存在具有相同指紋信息的文件，這種去冗方式的去冗速度非常快，缺點是即使2個文件中存在很多相同數據，也無法刪除文件內的重復數據[30].

主流的開源分布式文件系統大多針對大文件讀寫而專門設計，企業級的多媒體文件管理系統因商業利益無法公開.本文重點研究數據冗余度高的應用程序如何對多媒體文件進行分布式存儲的問題，與主流的分布式文件系統相比，本文實現的MFCSS(multimedia file cloud storage system)系統能夠運行在Windows或Linux下，不依賴數據庫，支持對多媒體文件進行數據去冗，支持對存儲目錄進行運行時動態邏輯擴容.

2 分布式存儲目錄建模方法及MFCSS系統

數據中心是一整套復雜的設施，它不僅包括計算機系統和其它與之配套的設備，還包含冗余的數據通信連接、環境控制設備、監控設備以及各種安全裝置[31].一個數據中心通常會包含多臺存儲服務器，存儲服務器自身會存在一些受保護的應用程序數據文件和存儲目錄，為了隔離不同應用程序的存儲區域，防止應用程序上傳的文件對存儲服務器自身的重要文件造成破壞，存儲服務器需要指定一些存儲目錄供應用程序存儲文件.

圖1描述了一個數據中心的分布式存儲目錄結構圖，它由多棵存儲目錄樹構成，不同的應用程序在保存用戶文件時通常具有不同的存儲目錄樹邏輯結構，存儲目錄樹中結點的層次關系取決于應用程序，本節將給出分布式存儲目錄建模方案中各結點的詳細定義.

Fig. 1 Distributed directory tree structure圖1 分布式存儲目錄結構圖

定義1. 存儲目錄結點(directory node,DN).用來描述存儲服務器上的存儲目錄信息，它定義為(id,naming,storePath,(parent,ChildNodes))，其中：

1)id表示DN的編號，編號具有唯一性.

2)naming表示DN的命名規則.它定義為三元組(nameType,staticName,dynamicName)，其中：

①nameType∈{static,dynamic}表示DN的命名方式，static表示DN采用靜態命名方式，dynamic表示DN采用動態命名方式.

②staticName表示DN采用靜態命名方式時候的文件名是staticName，例如：staticName=“Z1”，則該目錄的文件名為“Z1”.

③dynamicName表示DN采用動態命名方式時，將應用程序運行時傳遞的dynamicName所對應的參數的值作為DN的文件名，例如：dynamic-Name=“userId”，且應用程序運行時傳遞的參數userId=“U10”，則該目錄的文件名為“U10”.

3)storePath表示DN的初始設置結點的磁盤存儲路徑，初始設置結點AN(ancestor node)的定義參見下文.

4) (parent,ChildNodes)表示DN的直連結點的屬性信息，其中：

①parent表示DN的直接父結點.

②ChildNodes={node1,node2…,nodem}(m≥0)表示DN直接子結點的集合，其中nodei(0≤i≤m)可以是DN，也可以是文件結點(file node,FN)，FN的定義參見下文.

根據定義1，下面行文中定義靜態目錄結點SDN(static directory node)，它是DN的特殊實例，其名稱staticName在系統未運行時指定，為了防止同一個存儲目錄中出現2個具有相同文件名的存儲目錄，不同編號的SDN具有不同的目錄名稱；定義動態目錄結點DDN(dynamic directory node)，它也是DN的特殊實例，其編號在系統未運行時指定，但其名稱取決于系統運行過程中應用程序傳遞的dynamicName所對應的參數的值，一個DDN在系統運行過程中會產生多個具有不同文件名的DN，這些DN具有相同的父目錄；定義初始設置結點AN，它也是DN的特殊實例，它代表存儲服務器結點在應用程序運行之初提供的用來存放文件的存儲目錄，AN必須是實際存在的存儲目錄，其中AN.parent是存儲服務器結點，AN.storePath是該初始設置結點在磁盤上的絕對路徑.

例1. 在圖1所示的分布式存儲目錄結構圖中，“圖書”和“場景”分別是“電子書存儲服務器”和“場景存儲服務器”的初始設置結點，每個存儲服務器可以具有多個初始設置結點，但是每個存儲目錄結點只能隸屬于唯一的初始設置結點.

定義2. 存儲服務器結點(server node,SN).用來描述數據中心內存儲服務器的屬性信息、訪問信息和它所提供的初始設置結點信息，它定義為(id,property,access,AncestorNodes,url)，其中:

1)id表示SN的編號，編號具有唯一性.

2)property定義為(ip,ftpPort,serverPort)，表示SN的屬性.

①ip表示SN的IP地址.

②ftpPort表示通過FTP協議訪問SN的端口號.

③serverPort表示SN提供的外部TCP協議訪問端口號.

3)access定義為(userName,password)，表示SN的訪問信息.

①userName表示訪問SN的用戶名.

②password表示訪問SN的密碼.

4)AncestorNodes={AN1,AN2…,ANn}(n≥1)表示SN提供的可以存儲文件的初始設置結點集合.

5)url表示通過HTTP協議訪問SN的地址.

定義3. 文件結點.FN用來描述文件的相關信息，它定義為(id,fileName,fileType,property)，其中：

1)id表示FN的編號.

2)fileName表示文件名.

3)fileType表示文件類型.

4)property定義為(fingerprint,directory-NodeId)，它表示文件的屬性.其中：

①fingerprint表示文件的指紋信息，它在系統中可以是MD5，也可以是SHA-1等摘要算法.

②directoryNodeId表示FN的父存儲目錄結點的編號.

根據上文中對一些結點的定義，下面將給出存儲目錄子樹、存儲目錄樹和分布式存儲目錄的相關定義.

定義4. 存儲目錄子樹(SubTree).用于描述某一個存儲目錄結點及其嵌套子結點之間的關系，以存儲目錄結點node為根結點的存儲目錄子樹SubTree(node)定義為：

1) 如果node是文件結點，則SubTree(node)=node.

2) 如果node是存儲目錄結點，并且該存儲目錄結點沒有直接子結點，即node.ChildNodes=?,則SubTree(node)=node.

3) 如果node是存儲目錄結點，并且該存儲目錄結點具有直接子結點，假設：node.ChildNodes={node1,node2,…,nodem}(m≥1)，則SubTree(node)是由以node為根結點的m棵子樹{SubTree(node1),SubTree(node2),…,SubTree(nodem)}按從左到右順序構成的樹.

4) 用SubTree(node).id表示存儲目錄子樹的編號，且SubTree(node).id=node.id.

定義5. 存儲目錄樹(DirectoryTree).用于描述某一個存儲服務器結點(SN)及其嵌套子結點之間的關系，設SN.AncestorNodes={AN1,AN2,…,ANn}(n≥1)，則存儲目錄樹DirectoryTree(SN)是由以SN為根結點和n棵存儲目錄子樹SubTree(AN1),SubTree(AN2),…,SubTree(ANn)按從左到右順序構成的樹，用DirectoryTree.id表示存儲目錄樹DirectoryTree的編號，且DirectoryTree.id=SN.id.

定義6. 數據中心.可以看作一個分布式存儲目錄(DistributeTrees)，它由若干棵存儲目錄樹構成，即DistributeTrees={DirectoryTree(SN1),DirectoryTree(SN2),…,DirectoryTree(SNk)}(k≥1).

通過以上定義，整個數據中心可以被建模形成一棵分布式存儲目錄，分布式存儲目錄中的存儲目錄結點都是邏輯結點，應用程序可以通過該建模方案定義每個邏輯結點之間的關系以及邏輯結點的相關屬性，系統會在運行過程中根據應用程序傳遞的參數，把每個邏輯結點實例化為相應的物理存儲結點，應用程序在保存文件時只需要指定邏輯結點的編號，系統會把文件保存到邏輯結點對應的物理存儲結點中.

在分布式存儲目錄模型的基礎上實現的多媒體文件云存儲系統(MFCSS)解決了數據中心內多媒體文件的數據去冗問題，它可以給應用程序提供便捷的管理分布式存儲目錄的接口，簡化應用程序管理分布式存儲環境中多媒體文件的過程.整個系統的架構如圖2所示，MFCSS系統向應用程序提供多媒體文件云存儲服務，它由存儲接口管理子系統(storage interface management subsystem, SIMSS)、集群管理子系統(cluster management sub-system, CMSS)和存儲管理子系統(storage manage-ment subsystem, SMSS)構成，每個應用程序各集成一個存儲接口管理子系統，存儲接口管理子系統以JAR文件格式包的形式集成在應用程序中.

Fig. 2 System architecture of MFCSS圖2 多媒體文件云存儲系統架構

存儲接口管理子系統給應用程序提供操作數據文件的接口，包括文件操作相關接口和目錄操作相關接口等，同時負責生成操作指令與集群管理子系統和存儲管理子系統進行通信.它還負責管理應用程序自定義的存儲目錄樹，生成多媒體文件的存儲路徑和訪問路徑，當存儲服務器的存儲負荷達到一定閾值之后，存儲接口管理子系統會向集群管理子系統發送指令，對相應的存儲目錄進行邏輯擴容.

數據中心的每臺存儲服務器上都會部署一個存儲管理子系統，它負責管理其所在存儲服務器上所有文件元數據、文件引用信息和擴容狀態信息，并提供查詢文件元數據、查詢存儲目錄引用信息和查詢存儲目錄擴容狀態信息等服務.多個存儲管理子系統在查找文件指紋信息所對應文件元數據時是并行執行的，它們將各自的查找結果通過通信指令傳輸給集群管理子系統，集群管理子系統匯總各個存儲管理子系統發來的查找結果,并將結果返回給存儲接口管理子系統做后續的業務處理.

當存儲接口管理子系統在驗證多媒體文件是否屬于冗余文件時，通過集群管理子系統與不同的存儲管理子系統通信，當存儲接口管理子系統在保存多媒體文件時，它直接與存儲管理子系統通信.

集群管理子系統部署在單獨的服務器上，負責管理新接入的存儲服務器，監控各臺存儲服務器的運行狀態，提供對存儲目錄進行邏輯擴容的服務，同時還提供文件指紋信息匹配驗證服務.集群管理子系統中實現了一個布隆過濾器[32]負責管理MFCSS系統保存的所有文件指紋信息，在接收到存儲接口管理子系統發來的驗證文件指紋信息指令之后，它通過布隆過濾器判斷文件指紋信息的存在性，如果文件指紋信息不存在于布隆過濾器中，集群管理子系統判定用戶上傳文件不屬于冗余文件，否則，就將查找該指紋信息所對應文件元數據的指令發送給各個存儲管理子系統，進一步確定冗余文件的具體位置.每個存儲管理子系統根據指紋信息迅速在內存中找出該指紋信息所對應的文件元數據，集群管理子系統匯總所有存儲管理子系統發送給它的匹配結果，并把結果反饋給應用程序，由應用程序根據該反饋結果做后續的業務處理.

Fig. 3 The process of logical expansion圖3 邏輯擴容流程圖

數據中心的每臺存儲服務器都開啟了FTP訪問服務，供存儲接口管理子系統操作文件和目錄.應用程序在集成了存儲接口管理子系統之后，可以自定義分布式存儲目錄模型，然后調用存儲接口管理子系統提供的文件操作接口和目錄操作接口就可以完成對多媒體文件的存儲和查詢過程，存儲的過程中MFCSS系統會根據應用程序的需求對指定的存儲目錄或者整個存儲服務器中的數據進行去冗，當某個存儲服務器的磁盤空間利用率在超過一定的閾值之后，MFCSS系統會自動給該存儲服務器中的存儲目錄進行邏輯擴容，應用程序在存儲文件時不必擔心存儲目錄會出現磁盤存儲空間不足的情況.

MFCSS系統中的每個存儲服務器都由部署在其上的Apache提供多媒體文件的Web訪問服務，為了提高用戶文件的存儲安全性和訪問安全性，避免用戶文件被網絡爬蟲按照一定規則竊取，同時還要保證MFCSS系統保存的文件不被第三方應用程序訪問.存儲接口管理子系統會對用戶上傳的每個文件都生成一個時間戳并分配一個隨機數存儲于文件名中，它相當于每個多媒體文件的“私人秘鑰”，該秘鑰可以保證所有獲取文件的請求都是經過MFCSS系統“批準”的，可以有效防止網絡爬蟲根據某些已知文件的訪問路徑通過暴力破解的方式非法獲取到其他文件的訪問路徑.同時，應用程序在系統初始化時MFCSS系統會給它授權一個訪問編號，在保存文件和訪問文件時應用程序需要給MFCSS系統提供該編號，該編號相當于應用程序的“身份證”，可以有效防止第三方應用程序在知道了存儲目錄樹結構的情況下非法竊取MFCSS系統中的用戶文件.

3 存儲目錄邏輯擴容策略

為了提高系統的擴展性，保證文件系統服務的連續性，需要在系統運行過程中實時地給存儲目錄邏輯擴容.對于應用程序而言，它通過分布式存儲目錄模型可以定義存儲目錄的邏輯結構，在保存文件時應用程序只需要提供存儲目錄的邏輯結點編號以及相應的保存參數，MFCSS系統會維護邏輯結點到物理存儲結點之間的映射關系.應用程序可以源源不斷地把文件保存在某個存儲目錄邏輯結點中，不需要擔心該結點對應的磁盤空間出現不足的問題，MFCSS系統在保存文件時如果發現某個磁盤的存儲空間出現不足，會自動的給相應的存儲目錄邏輯擴容.

圖3所示是MFCSS系統邏輯擴容的具體流程，主要步驟如下：

1) 存儲接口管理子系統發送獲取擴容存儲目錄指令給集群管理子系統；

2) 集群管理子系統收到獲取擴容存儲目錄指令，發送獲取服務器運行狀態指令給所有的存儲管理子系統；

3) 每個存儲管理子系統收到獲取服務器運行狀態指令，將服務器運行狀態返回給集群管理子系統；

4) 集群管理子系統匯總所有的存儲服務器運行狀態，確定空閑的存儲服務器并生成擴容存儲目錄，然后保存擴容信息，并將擴容存儲目錄信息返回給存儲接口管理子系統.

圖4所示為一個具有擴容狀態的分布式存儲目錄示意圖，假設應用程序通過MFCSS系統向存儲目錄樹DirectoryTree(SN2)中的靜態目錄結點F14添加一個文件結點fileNode1，則MFCSS系統進行2項判斷：

1) 如果存儲服務器結點SN2的磁盤存儲空間利用率未超過其存儲上限，那么fileNode1會被保存到結點F14中；

2) 如果存儲服務器結點SN2的磁盤存儲空間利用率超過了其存儲上限，此時系統會為結點F14分配一個擴容結點并把fileNode1保存到該擴容結點中.

Fig. 4 Distributed directory tree structure with expand status圖4 具有擴容狀態的分布式存儲目錄示意圖

任何一個存儲服務器結點的磁盤存儲空間利用率超過了其存儲上限之后，MFCSS系統會給映射在其上的存儲目錄結點進行邏輯擴容，如果應用程序需要獲取某個被擴容過的存儲目錄結點中的所有文件，MFCSS系統會自動把該存儲目錄結點對應的實際磁盤目錄中的文件，還有存放在其擴容結點對應的實際磁盤目錄中的文件一起返回給應用程序.該存儲目錄邏輯擴容機制使每個邏輯存儲目錄結點都能映射到多個實際磁盤存儲目錄，保證了文件系統服務的連續性，同時有效利用了存儲服務器的磁盤空間.

4 數據去冗策略

Fig. 5 The process of deleting redundant files圖5 數據去冗流程圖

隨著集群規模的擴大和存儲多媒體文件的數量增加，為了降低整個云存儲系統的運行成本，需要對系統中保存的多媒體文件進行數據去冗，節省磁盤占用空間.圖5所示是多媒體文件云存儲系統數據去冗的具體流程，整個去冗流程主要分為3個階段：判定階段、確認階段和存儲階段.在判定階段，應用程序將文件指紋信息發送給多媒體文件云存儲系統，系統中的布隆過濾器快速判定該指紋信息是否存在，如果布隆過濾器中不存在該文件的指紋信息，系統就認為該文件不屬于冗余文件，否則就進入確認階段進一步確定文件的存在性.在確認階段，系統通過通信指令告訴所有存儲服務器上的客戶端，使它們各自查找該指紋信息所對應的文件元數據，并將查找結果匯總反饋給應用程序，只要某個客戶端找到了該指紋信息所對應的文件元數據，系統就認為該文件屬于冗余文件.系統在以上2個階段運行結束之后進入存儲階段，在該階段系統保存相關的文件引用信息和文件指紋信息等核心數據.

具體的數據去冗步驟如下：

步驟1. 針對用戶上傳的多媒體文件，通過瀏覽器計算該多媒體文件的指紋信息并傳輸給應用程序.

用戶在通過瀏覽器訪問應用程序并上傳文件時，應用程序提供的瀏覽器頁面上的JavaScript腳本首先計算文件的指紋信息并將它發送給應用程序.

步驟2. 應用程序獲取到該多媒體文件的指紋信息，調用存儲接口管理子系統的接口生成驗證文件指紋信息指令.

應用程序通過存儲接口管理子系統向集群管理子系統發送驗證文件指紋信息指令；應用程序在存儲文件和訪問文件時需要提供MFCSS系統授權給它的編號，只有經過MFCSS系統認證才能進行后續的文件操作和目錄操作，存儲接口管理子系統對用戶上傳的每個文件都生成一個時間戳并分配一個隨機數存儲在文件名中，這種設計可以在不影響MFCSS系統服務效率的同時保證用戶數據的訪問安全.

步驟3. 存儲接口管理子系統把驗證文件指紋信息指令發送給集群管理子系統.

步驟4. 集群管理子系統在收到驗證文件指紋信息指令后，判斷該多媒體文件的指紋信息是否存在，如果存在，進入步驟5；否則，生成文件指紋信息驗證結果，進入步驟7.

如果集群管理子系統通過布隆過濾器判斷得出該指紋信息已存在，則系統需要進一步找到該指紋信息所對應的文件元數據，在查找指紋信息所對應的文件元數據過程中，集群管理子系統給每個存儲管理子系統發送查找文件元數據的指令，把存儲管理子系統返回的查找結果匯總并發送給存儲接口管理子系統，否則，生成文件指紋信息驗證結果并發送給存儲接口管理子系統.

集群管理子系統在找到與用戶上傳的多媒體文件具有相同指紋信息的文件后，會把文件元數據返回給應用程序，由應用程序根據文件元數據進行后續的業務處理，防止用戶無法訪問到該文件的情況發生；

步驟5. 集群管理子系統發送查找該指紋信息對應的文件元數據指令給所有的存儲管理子系統.

在查找文件指紋信息所對應文件元數據的過程中，每個存儲管理子系統的查找過程是并行的，有效提高了定位冗余文件的速度，提升了用戶體驗.

步驟6. 每個存儲管理子系統收到查找文件元數據指令，在各自的內存中查找該多媒體文件指紋對應的文件元數據，并生成文件指紋信息驗證結果返回給集群管理子系統.

步驟7. 集群管理子系統匯總文件指紋信息驗證結果，并發送給存儲接口管理子系統.

步驟8. 存儲接口管理子系統獲取文件指紋信息驗證結果，根據結果判斷MFCSS系統中是否存在相同文件，如果存在，進入步驟9；否則，進入步驟10.

步驟9. 向存儲管理子系統發送添加文件引用信息指令和增加文件引用頻率指令，并生成文件上傳結果；然后進入步驟14.

存儲接口管理子系統根據集群管理子系統發來的消息判斷用戶上傳的文件是否屬于冗余文件，如果MFCSS系統中的存儲服務器SNi上已經存在一個文件filex和用戶上傳的文件具有相同的指紋信息，則應用程序把它分配的用來保存該多媒體文件的存儲目錄結點編號idx傳遞給存儲接口管理子系統，然后存儲接口管理子系統向idx所在的存儲管理子系統發送添加文件引用信息的指令，收到該指令之后，存儲管理子系統會保存idx和filex之間的映射關系；之后存儲接口管理子系統向filex所在的存儲管理子系統發送增加文件引用頻率的指令，收到該指令之后，存儲管理子系統會找到filex的元數據并對其引用頻率加1.如果MFCSS系統中已經存在某個文件與用戶上傳的文件具有相同的指紋信息，則中斷用戶文件的上傳過程并提示文件秒傳成功，減少了用戶上傳文件需要消耗的平均時間，同時降低了存儲服務器的存儲負載和數據中心的存儲成本；如果MFCSS系統內不存在某個文件與用戶上傳的文件具有相同的指紋信息，則存儲接口管理子系統向應用程序請求文件的二進制流.

步驟10. 應用程序獲取用戶待上傳的多媒體文件流，并傳輸文件流和應用程序指定的存儲目錄結點編號給存儲接口管理子系統.

步驟11. 存儲接口管理子系統生成存儲目錄結點編號對應的存儲目錄對象，并獲取該存儲目錄的磁盤存儲空間利用率，之后根據磁盤存儲空間利用率判斷該存儲目錄是否需要擴容，如果存儲目錄需要擴容，則存儲接口管理子系統獲取擴容存儲目錄，然后生成文件保存路徑；否則，直接生成文件保存路徑.

存儲接口管理子系統根據應用程序指定的存儲目錄編號生成保存文件流的存儲目錄對象，之后存儲接口管理子系統通過該存儲目錄編號所在存儲管理子系統獲取該存儲目錄的磁盤存儲空間利用率，如果此時存儲接口管理子系統發現該存儲目錄所在的存儲服務器的磁盤空間利用率已經達到指定的閾值，則存儲接口管理子系統根據圖4描述的邏輯擴容流程，向集群管理子系統發送給該存儲目錄邏輯擴容的指令，然后獲取到擴容的存儲目錄對象，之后存儲接口管理子系統就會把文件流保存到擴容存儲目錄中.

步驟12. 存儲接口管理子系統對用戶待上傳的多媒體文件類型進行識別，并判斷文件類型是否合法，如果合法，則生成文件名，進入步驟13，否則，生成文件上傳結果，進入步驟14.

存儲接口管理子系統根據文件流識別用戶上傳多媒體文件的文件類型，如果文件類型合法，則存儲接口管理子系統生成一個時間戳并分配一個隨機數作為文件名；如果文件類型不合法，則生成相應的文件上傳結果.

步驟13. 存儲接口管理子系統保存文件，并向集群管理子系統發送添加文件指紋信息指令，同時向存儲管理子系統發送添加文件元數據指令，并生成文件上傳結果.

如果應用程序分配的保存該多媒體文件的存儲目錄idx不需要擴容，則存儲接口管理子系統把用戶上傳的多媒體文件流保存到應用程序指定的存儲目錄idx中，否則，集群管理子系統會給存儲目錄idx分配一個擴容存儲目錄idy并記錄相關擴容信息，然后存儲接口管理子系統把用戶上傳的多媒體文件流保存到擴容后的存儲目錄idy中.文件流被保存之后，存儲接口管理子系統向集群管理子系統發送添加文件指紋信息指令，集群管理子系統收到指令之后會把該文件的指紋信息添加到布隆過濾器中.如果idx沒有被擴容，則存儲接口管理子系統向idx所在的存儲管理子系統發送添加文件元數據指令，否則，存儲接口管理子系統向擴容存儲目錄idy所在的存儲管理子系統發送添加文件元數據指令.存儲管理子系統收到指令之后會保存該文件的元數據信息.

步驟14. 應用程序獲取文件上傳結果，并發送文件上傳結果給用戶.

步驟15. 用戶查看文件上傳結果，多媒體文件被保存到了MFCSS系統中.

為了快速地確定數據中心內是否存在某個文件與用戶上傳的文件具有相同的指紋信息，效率最高的方案是將所有的文件元數據都加載到服務器的內存中，每次查詢時在內存中進行匹配，但是考慮到服務器內存大小的限制，以及MFCSS系統在運行的過程中文件數量會快速增長，所有的文件元數據很難全部加載到一臺服務器的內存中.在MFCSS系統中，每個存儲管理子系統都將它所管理的存儲服務器上的全部文件元數據從磁盤預加載到內存中，并維護文件指紋信息和文件元數據之間的映射關系，這樣整個數據中心內全部的文件元數據都分散存儲于各臺存儲服務器的內存中，充分利用了每臺服務器的內存空間，并且在匹配文件指紋信息的過程中多個存儲管理子系統的匹配過程是并行執行的，有效的提高了冗余文件的定位速度，提升了用戶存儲文件的交互體驗.

5 實驗結果與分析

為了評估MFCSS系統的各項性能指標，對系統做了如下測試：寫性能測試、系統響應時間測試、系統吞吐量測試、集群管理子系統和存儲管理子系統內存使用情況測試以及磁盤占用空間測試.為了比較MFCSS與HDFS在保存具有不同冗余度的多媒體文件時性能的差異，在相同的測試環境下搭建了HDFS原型系統.集成了存儲接口管理子系統的應用程序服務器具有4 GB內存，處理器是Intel?CoreTM2 Duo CPU P9400@2.40 GHz；部署集群管理子系統的服務器具有16 GB內存，處理器是Intel?CoreTMi7-4610M CPU@3.00 GHz，同時它還作為HDFS命名空間結點；2臺部署存儲管理子系統的服務器具有2 GB內存，處理器是Intel?CoreTM2 Duo CPU E7500@2.93 GHz，同時這2臺服務器還作為HDFS數據結點.整個實驗環境都在以太網交換機構建的局域網中，使用的交換機是傳輸速率為100 Mbps的TP-LINK TL-SF1008.

5.1 寫性能測試

為了評估MFCSS系統在用戶上傳不同大小多媒體文件情況下系統的寫性能，實驗過程中使用了具有不同大小的17類多媒體文件，每類文件都由數據冗余度為0%，25%，40%，50%的樣本構成，實驗過程中對各類型的文件分別做了10次實驗，分析寫性能時使用的是這10次實驗結果的平均值.北京理工大學的焦晨宇[33]在2015年研究了一種可伸縮的分布式文件系統SDFS，并針對海量小文件存儲進行了性能優化.為了對比不同文件系統寫性能的差異，本文對HDFS，SDFS，MFCSS系統的寫性能做了對比，圖6顯示了這3個文件系統之間寫性能的差異，其中SDFS的實驗數據來源于焦晨宇的論文.

Fig. 6 The writing performance of MFCSS圖6 MFCSS系統寫性能

MFCSS系統在保存非冗余文件時需要由存儲接口管理子系統動態生成文件的保存路徑，集群管理子系統需要保存文件指紋信息，存儲管理子系統需要保存文件元數據，同時存儲接口管理子系統需要把文件流傳輸到存儲服務器上，這些操作結束之后文件就保存成功了.如果MFCSS系統保存的是冗余文件，那么系統只需保存相關的引用信息就會提示用戶文件保存成功.HDFS和SDFS由于沒有數據去冗措施，因此在保存數據冗余度較高的多媒體文件時，本文實現的MFCSS系統的性能要優于其他2個文件系統，而且MFCSS系統的性能優勢隨著數據冗余度的提高會變得更加顯著.

5.2 系統響應時間測試

為了評估MFCSS系統在保存多媒體文件時系統的響應時間，實驗過程中使用了大量內容不同的小文件，這些文件的平均大小為100 KB，實驗過程中分別對HDFS和MFCSS系統執行讀寫操作各200次，統計系統讀寫的平均響應時間，其中SDFS的實驗數據來源于焦晨宇同學的論文[33].

圖7所示為HDFS，SDFS，MFCSS系統響應時間的差異.從圖7中可以看出本文實現的多媒體文件云存儲系統MFCSS在小文件的讀寫上相較于HDFS和SDFS有更好的性能優勢，平均響應時間遠低于HDFS，同時也優于SDFS.

Fig. 7 The system response time圖7 系統響應時間

5.3 系統吞吐量測試

為了測試存儲目錄邏輯擴容策略的有效性，證明此方法可以有效提高系統的運行效率，實驗過程中采用的數據集是100個具有不同內容的1MB大小的文件，模擬了多用戶并發上傳文件的場景，測試了系統從1臺存儲服務器逐漸擴容到3臺存儲服務器時各個階段的吞吐量，每次實驗都做了10次并取平均值作為實驗結果.

圖8所示是系統吞吐量的測試結果，隨著MFCSS系統存儲服務器的增加，系統的吞吐量逐漸提高，但增加了存儲服務器后系統的吞吐量優勢并非立刻展現出來，因為增加存儲服務器的同時系統會增加內存資源、CPU資源和網絡等資源的消耗，隨著并發用戶數的增加吞吐量的優勢才能得以展現.在實驗環境下，當云存儲系統的存儲服務器數量從1臺擴展到2臺時，并發用戶數在9以內并不能顯示出擴容優勢，只有并發用戶數超過了9個，具有2臺存儲服務器的系統才會比具有1臺存儲服務器的系統具有更高的吞吐量.當云存儲系統的存儲服務器數量從2臺擴展到3臺時，系統的吞吐量優勢在并發用戶數為5時就開始展現出來，并隨著并發用戶數的增加，具有3臺存儲服務器的系統具有更加明顯的性能優勢.

Fig. 8 The throughput of MFCSS圖8 系統吞吐量

5.4 內存使用測試

在評估MFCSS系統的內存使用情況時，分別測試了用戶上傳2 000，4 000，6 000，8 000，10 000個文件的情況下，集群管理子系統和存儲管理子系統各自的內存占用情況，在相同測試環境下測試了HDFS原型系統在保存這些文件時命名空間結點和數據結點的內存使用情況.其中圖9(a)表示集群管理子系統與HDFS命名空間結點的內存使用實驗結果，圖9(b)表示存儲管理子系統與HDFS數據結點的內存使用實驗結果.

Fig. 9 The memory usage of MFCSS comparing with HDFS圖9 MFCSS與HDFS的內存使用對比

從圖9(a)可知，在保存相同個數文件的情況下，集群管理子系統使用的內存少于HDFS命名空間結點，主要是因為HDFS命名空間結點保存了HDFS集群中所有的文件元數據，而MFCSS系統的集群管理子系統僅保存了文件元數據中的文件指紋信息，因此HDFS命名空間結點消耗更多的內存.從圖9(b)可知，即使存儲管理子系統把它所在的存儲服務器上所有文件元數據都加載到內存中，它需要使用的內存空間依然少于HDFS數據結點，主要是因為HDFS原型系統的數據結點需要維護每個數據塊的塊報告(block report)以及其他數據塊相關信息，因此它需要消耗更多的內存空間.

5.5 磁盤占用空間測試

為了評估MFCSS系統在節省磁盤占用空間方面的性能，實驗過程中把系統部署在課題組局域網后，供課題組的其他成員通過本系統上傳多媒體文件，圖10所示為10周之內課題組成員通過MFCSS系統累計上傳的多媒體文件總量和這些文件實際占用磁盤空間的對比圖.

Fig. 10 The disk usage of MFCSS圖10 磁盤占用空間

在剛開始的幾周里，MFCSS系統積累的用戶數據較少，因此用戶上傳的多媒體文件都需要保存到磁盤中，過一段時間之后MFCSS系統積累了大量用戶數據，因此用戶上傳的多媒體文件會越來越多的被系統判定為冗余文件，此時系統只會記錄相關的文件引用信息，并不會重復的保存用戶數據，因此用戶累計上傳的文件大小和這些文件的實際磁盤占用空間之間的差距逐漸增大，而且差距越來越明顯.

6 總 結

本文分析了目前主流的分布式文件系統的優點和不足，為了解決數據冗余度高的應用程序在低存儲成本條件下對多媒體文件進行分布式存儲的難題，提出了一種分布式存儲目錄建模方案，該建模方案具有很高的靈活性，允許應用程序自定義存儲目錄樹的結構.為了去除數據中心內重復的多媒體文件數據，提出了一種數據去冗方案，并在降低了存儲成本且不影響用戶體驗的情況下，解決了多媒體文件在MFCSS系統內的數據去冗難題.在識別重復數據的過程中，使用布隆過濾器加快了識別冗余文件的速度.基于分布式存儲目錄建模方案實現的MFCSS系統，簡化了應用程序管理分布式環境中多媒體文件的過程，在保存數據冗余度較高的多媒體文件時具有良好的寫性能，可以有效提高磁盤的存儲效率，同時具備良好的擴展性，還可以加快用戶與MFCSS系統之間傳輸文件的平均速度.

在未來的工作中，為提高系統的可靠性，將會使用副本策略保護MFCSS系統中存儲的文件，提高系統的可靠性，同時將會對多媒體文件進行分類，不同類型的多媒體文件由不同的布隆過濾器進行管理，進一步提高冗余文件的定位速度.

[1]Fu Yinxun, Luo Shengmei, Shu Jiwu. Survey of secure cloud storage system and key technologies[J]. Journal of Computer Research and Development, 2013, 50(1): 136-145 (in Chinese)

(傅穎勛, 羅圣美, 舒繼武. 安全云存儲系統與關鍵技術綜述[J]. 計算機研究與發展, 2015, 50(1): 136-145)

[2]Liu Jian, Huang Kun, Rong Hong, et al. Privacy-preserving public auditing for regenerating-code-based cloud storage[J]. IEEE Trans on Information Forensics and Security, 2015, 10(7): 1513-1528

[3]Lü Yisheng, Duan Yanjie, Kang Wenwen, et al. Traffic flow prediction with big data: A deep learning approach[J]. IEEE Trans on Intelligent Transportation Systems, 2015, 16(2): 865-873

[4]Vandenbroucke K, Ferreira D, Goncalves J, et al. Mobile cloud storage: A contextual experience[C] //Proc of the 16th Int Conf on Human-computer Interaction with Mobile Devices & Services. New York: ACM, 2014: 101-110

[5]Eyben F, Weninger F, Gross F, et al. Recent developments in opensmile, the munich open-source multimedia feature extractor[C] //Proc of the 21st ACM Int Conf on Multimedia. New York: ACM, 2013: 835-838

[6]Armbrust M, Fox A, Griffith R, et al. A view of cloud computing[J]. Communications of the ACM, 2010, 53(4): 50-58

[7]Zhao Zhenpeng, Badam S K, Chandrasegaran S, et al. A multimedia sketching system for collaborative creativity[C] //Proc of the 32nd Annual ACM Conf on Human Factors in Computing Systems. New York: ACM, 2014: 1235-1244

[8]Dinh H T, Lee C, Niyato D, et al. A survey of mobile cloud computing: architecture, applications, and approaches[J]. Wireless Communications and Mobile Computing, 2013, 13(18): 1587-1611

[9]Kwon S J. A cache-based flash translation layer for TLC-based multimedia storage devices[J]. ACM Trans on Embedded Computing Systems, 2016, 15(1): 11-12

[10]Levi A, Mokryn O, Diot C, et al. Finding a needle in a haystack of reviews: Cold start context-based hotel recommender system[C] //Proc of the 6th ACM Conf on Recommender Systems. New York: ACM, 2012: 115-122

[11]Duan Huiying, Liu Feifei. Building and managing reputation in the environment of Chinese e-commerce: A case study on Taobao[C] //Proc of the 2nd Int Conf on Web Intelligence, Mining and Semantics. New York: ACM, 2012: 43-49

[12]Ross R B, Thakur R. PVFS: A parallel file system for Linux clusters[C] //Proc of the 4th Annual Linux Showcase and Conf. Berkeley, CA: USENIX Association, 2000: 391-430

[13]Piernas J, Nieplocha J, Felix E J. Evaluation of active storage strategies for the lustre parallel file system[C] //Proc of ACM/IEEE Conf on Supercomputing. New York: ACM, 2007: 28-30

[14]Ghemawat S, Gobioff H, Leung S T. The Google file system[J]. ACM SIGOPS Operating Systems Review, 2003, 37(5): 29-43

[15]Shvachko K, Kuang H, Radia S, et al. The hadoop distributed file system[C] //Proc of the 26th IEEE Conf on Mass Storage Systems and Technologies. Piscataway, NJ: IEEE, 2010: 7-13

[16]Chu Yu. Taobao file system[OL]. [2016-05-06] http://code.taobao.org/p/tfs/wiki/intro/

[17]Kubiatowicz J, Bindel D, Chen Y, et al. Oceanstore: An architecture for global-scale persistent storage[J]. ACM SIGPLAN Notices, 2000, 35(11): 190-201

[18]Adya A, Bolosky W J, Castro M, et al. FARSITE: Federated, available, and reliable storage for an incompletely trusted environment[J]. ACM SIGOPS Operating Systems Review, 2002, 36(1): 9-14

[19]Weil S A, Brandt S A, Miller E L, et al. Ceph: A scalable, high-performance distributed file system[C] //Proc of the 7th Symp on Operating Systems Design and Implementation. Berkeley: USENIX Association, 2006: 307-320

[20]Burns A, Wellings A. Real-Time Systems and Programming Languages: Ada, Real-Time Java and C/Real-Time POSIX[M]. Boston: Addison-Wesley Educational Publishers Inc, 2009

[21]Chung C-Y, Lee C-L, Liu T-J. A high performance and low cost distributed file system[C] //Proc of the 2nd Int Conf on Software Engineering and Service Science (ICSESS). Piscataway, NJ: IEEE, 2011: 47-50

[22]Hao Peng, Wang Lirong, Wang Jiacai, et al. Design and implement of file linked distributed file system[C] //Proc of Conf on the Computer Science and Information Engineering. Piscataway, NJ: IEEE, 2009: 305-309

[23]Xiong Jin, Li Jianyu, Tang Rongfeng, et al. Improving data availability for a cluster file system through replication[C] //Proc of the 6th Conf on the Parallel and Distributed Processing. Piscataway, NJ: IEEE, 2008: 7-15

[24]Cao Liang, Wang Yu, Xiong Jin. Building highly available cluster file system based on replication[C] //Proc of the 7th Conf on the Parallel and Distributed Computing. Piscataway, NJ: IEEE, 2009: 94-101

[25]Chao H-C, Liu T-J, Kong-H, et al. A seamless and reliable distributed network file system utilizing webspace[C] //Proc of the 10th Int Symp on Web Site Evolution. Piscataway, NJ: IEEE, 2008: 65-68

[26]Dong Bo, Qiu Jie, Zheng Qinghua, et al. A novel approach to improving the efficiency of storing and accessing small files on Hadoop: A case study by PowerPoint files[C] //Proc of Conf on the Services Computing (SCC). Piscataway, NJ: IEEE, 2010: 65-72

[27]Dong Bo, Zheng Qinghua, Tian Feng, et al. An optimized approach for storing and accessing small files on cloud storage[J]. Journal of Network and Computer Applications, 2012, 35(6): 1847-1862

[28]Chandrasekar S, Dakshinamurthy R, Seshakumar P G, et al. A novel indexing scheme for efficient handling of small files in hadoop distributed file system[C] //Proc of Conf on the Computer Communication and Informatics (ICCCI). Piscataway, NJ: IEEE, 2008: 5-9

[29]Vorapongkitipun C, Nupairoj N. Improving performance of small-file accessing in Hadoop[C] //Proc the 11th of Conf on Computer Science and Software Engineering (JCSSE). Piscataway, NJ: IEEE, 2014: 200-205

[30]Fu Yinjin, Xiao Nong, Liu Fang. Research and development on key techniques of data deduplication[J]. Journal of Computer Research and Development, 2012, 49(1): 12-20 (in Chinese)

(付印金, 肖儂, 劉芳. 重復數據刪除關鍵技術研究進展[J]. 計算機研究與發展, 2012, 49(1): 12-20)

[31]Boucher T D, Auslander D M, Bash C E, et al. Viability of dynamic cooling control in a data center environment[J]. Journal of Electronic Packaging, 2006, 128(2): 137-144

[32]Song Haoyu, Dharmapurikar S, Turner J, et al. Fast Hash table lookup using extended bloom filter: An aid to network processing[J]. ACM SIGCOMM Computer Communication Review, 2005, 35(4): 181-192

[33]Jiao Chenyu. The design and application of a scalable distributed file system [D]. Beijing: Beijing Institute of Technology, 2015 (in Chinese)

(焦晨宇. 可伸縮分布式文件系統及其應用[D]. 北京: 北京理工大學, 2015)