本發(fā)明涉及存儲技術(shù)領(lǐng)域，特別是涉及一種文件處理方法和一種文件處理裝置。

背景技術(shù)：

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展和大數(shù)據(jù)時代的到來，出現(xiàn)了各種各樣的云計算服務(wù)，目前的云計算服務(wù)可以將海量的文件存儲在分布式文件系統(tǒng)中，并向應(yīng)用程序提供文件獲取服務(wù)。對于需要實時處理的在線應(yīng)用程序而言，分布式文件系統(tǒng)中文件的獲取性能會直接影響到其對應(yīng)請求的響應(yīng)時間，因此對分布式文件系統(tǒng)中文件的獲取性能提出了較高的要求。

HDFS(Hadoop分布式文件系統(tǒng)，Hadoop Distributed File System)具有高容錯性的特點，它將數(shù)據(jù)以一個或多個副本的形式分散存儲在多臺計算設(shè)備上，可以存儲海量數(shù)據(jù)，并且可靠性高，提供對數(shù)據(jù)快速的、可擴(kuò)展的訪問，適用于一次寫入、多次讀取的訪問模式。

發(fā)明人在實施例本發(fā)明的過程中發(fā)現(xiàn)，現(xiàn)有的HDFS是通過文件列表枚舉方式獲取文件的。具體地，HDFS的名稱節(jié)點需要維護(hù)文件目錄與數(shù)據(jù)塊之間的關(guān)系、以及數(shù)據(jù)塊與數(shù)據(jù)節(jié)點之間的關(guān)系，這樣，在接收來自客戶端的文件訪問請求后，需要依據(jù)文件目錄與數(shù)據(jù)塊之間的關(guān)系查詢組成待訪問文件的數(shù)據(jù)塊列表，并依據(jù)該數(shù)據(jù)塊與數(shù)據(jù)節(jié)點之間的關(guān)系查詢該數(shù)據(jù)塊列表被存儲在哪幾個數(shù)據(jù)節(jié)點上，然后從查詢得到的數(shù)據(jù)節(jié)點上讀取待訪問文件的數(shù)據(jù)?？梢姡F(xiàn)有的HDFS獲取文件的過程較為繁瑣，因此影響了文件的獲取效率，進(jìn)而影響了在線應(yīng)用程序的響應(yīng)性能。

發(fā)明人在實施例本發(fā)明的過程中還發(fā)現(xiàn)，現(xiàn)有的HDFS僅僅適用于一次寫入、多次查詢的情況，而不支持并發(fā)寫的情況，這樣將影響在線應(yīng)用程序的吞吐量。

技術(shù)實現(xiàn)要素：

鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的一種文件處理方法和一種文件處理裝置。

依據(jù)本發(fā)明的一個方面，提供了一種文件處理方法，包括：

接收文件處理請求；

對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理。

可選地，所述文件處理請求包括：文件下載請求，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上讀取所述待處理文件的文件內(nèi)容；

下載所述待處理文件的文件內(nèi)容。

可選地，所述文件處理請求包括：文件刪除請求，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

依據(jù)所述存儲路徑，在所述第二分布式文件系統(tǒng)上刪除所述待處理文件的文件內(nèi)容；

在所述第一分布式文件系統(tǒng)上刪除所述待處理文件的基本信息。

可選地，所述文件處理請求包括：文件狀態(tài)查詢請求，所述基本信息還包括文件狀態(tài)信息，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

從所述待處理文件的基本信息中獲取文件狀態(tài)信息，并將所述文件狀態(tài)信息作為處理結(jié)果返回。

可選地，所述文件處理請求包括：文件上傳請求，所述基本信息還包括：上傳完成標(biāo)識，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

依據(jù)所述基本信息中的上傳完成標(biāo)識，判斷是否完成所述待處理文件的上傳；

當(dāng)確定完成所述待處理文件的上傳時，返回完成上傳的處理結(jié)果。

可選地，所述基本信息還包括：處理狀態(tài)標(biāo)識，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，還包括：

當(dāng)確定未完成所述待處理文件的上傳時，依據(jù)所述基本信息中的處理狀態(tài)標(biāo)識判斷所述待處理文件是否存在處理異常；

當(dāng)確定所述待處理文件存在處理異常時，在第二文件系統(tǒng)上進(jìn)行所述待處理文件的異常處理；

在完成所述異常處理后，依據(jù)所述待處理文件在第二文件系統(tǒng)上的存儲狀態(tài)判斷所述待處理文件是否被成功上傳；

當(dāng)確定所述待處理文件被成功上傳時，返回成功上傳的處理結(jié)果。

可選地，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，還包括：

當(dāng)確定所述待處理文件不存在處理異常、或者確定所述待處理文件未被成功上傳時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

可選地，所述方法還包括：

當(dāng)?shù)谝环植际轿募到y(tǒng)上不存在所述待處理文件的基本信息時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

可選地，所述方法還包括：

接收隨機(jī)掃描請求；所述隨機(jī)掃描請求中攜帶有需要隨機(jī)掃描的主鍵；

從第一分布式文件系統(tǒng)上讀取所述需要隨機(jī)掃描的主鍵對應(yīng)文件在第二分布式文件系統(tǒng)上的存儲路徑；

依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上獲取所述需要隨機(jī)掃描的主鍵對應(yīng)文件的文件內(nèi)容；

利用掃描工具進(jìn)行所獲取文件內(nèi)容的掃描。

根據(jù)本發(fā)明的另一方面，提供了一種文件處理裝置，包括：

請求接收模塊，用于接收文件處理請求；

目錄加鎖模塊，用于對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

信息獲取模塊，用于從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

請求處理模塊，用于依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理。

根據(jù)本發(fā)明實施例的一種文件處理方法和裝置，當(dāng)存在對于文件的處理(如訪問)需求時，可以從第一分布式文件系統(tǒng)上獲取文件在第二分布式文件系統(tǒng)上的存儲路徑，相對于現(xiàn)有的HDFS是通過文件列表枚舉方式獲取文件，可以實現(xiàn)待處理文件的快速定位，因此可以提高文件的處理效率，進(jìn)而可以提高在線應(yīng)用程序的訪問性能。

并且，本發(fā)明實施例可以對待處理文件所屬的文件目錄進(jìn)行加鎖，這樣，在并發(fā)訪問(也即多用戶同時訪問)的場景下，上述加鎖處理可以使得同一時刻僅有一個用戶訪問分布式文件，故能夠有效解決多用戶訪問帶來的訪問沖突問題，進(jìn)而有效保證分布式文件的一致性，因此，本發(fā)明實施例可以支持并發(fā)訪問，進(jìn)而提高在線應(yīng)用程序的吞吐量。

上述說明僅是本發(fā)明技術(shù)方案的概述，為了能夠更清楚了解本發(fā)明的技術(shù)手段，而可依照說明書的內(nèi)容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式。

附圖說明

通過閱讀下文可選實施方式的詳細(xì)描述，各種其他的優(yōu)點和益處對于本領(lǐng)域普通技術(shù)人員將變得清楚明了。附圖僅用于示出可選實施方式的目的，而并不認(rèn)為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

圖1示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；

圖2示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；

圖3示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；

圖4示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；

圖5示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；

圖6示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；

圖7示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；

圖8示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程示意圖；以及

圖9示出了根據(jù)本發(fā)明一個實施例的一種文件處理裝置的結(jié)構(gòu)示意。

具體實施方式

下面將參照附圖更詳細(xì)地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應(yīng)當(dāng)理解，可以以各種形式實現(xiàn)本公開而不應(yīng)被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達(dá)給本領(lǐng)域的技術(shù)人員。

本發(fā)明實施例采用第一分布式文件系統(tǒng)和第二分布式文件系統(tǒng)進(jìn)行文件的存儲，其中，第一分布式文件系統(tǒng)可用于存儲文件的基本信息，如文件主鍵(key)、文件在第二分布式文件系統(tǒng)上的存儲路徑、文件大小、文件名、文件狀態(tài)信息等信息，第二分布式文件系統(tǒng)可用于存儲文件內(nèi)容，這樣，這樣，當(dāng)存在對于文件的處理(如訪問)需求時，可以從第一分布式文件系統(tǒng)上獲取文件在第二分布式文件系統(tǒng)上的存儲路徑，相對于現(xiàn)有的HDFS是通過文件列表枚舉方式獲取文件，可以實現(xiàn)待處理文件的快速定位，因此可以提高文件的處理效率，進(jìn)而可以提高在線應(yīng)用程序的訪問性能。

并且，本發(fā)明實施例可以對待處理文件所屬的文件目錄進(jìn)行加鎖，這樣，在并發(fā)訪問(也即多用戶同時訪問)的場景下，上述加鎖處理可以使得同一時刻僅有一個用戶訪問分布式文件，故能夠有效解決多用戶訪問帶來的訪問沖突問題，進(jìn)而有效保證分布式文件的一致性，因此，本發(fā)明實施例可以支持并發(fā)訪問，進(jìn)而提高在線應(yīng)用程序的吞吐量。

參照圖1，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟101、接收文件處理請求；

本發(fā)明實施例可以應(yīng)用于服務(wù)端的文件處理系統(tǒng)中，該文件處理系統(tǒng)可以基于所存儲的分布式文件向客戶端提供文件處理服務(wù)，也可以根據(jù)業(yè)務(wù)請求對所存儲的分布式文件進(jìn)行維護(hù)。

在實際應(yīng)用中，可以接收客戶端發(fā)送的文件處理請求?？蛇x地，上述文件處理請求可以包括如下請求中的至少一種：

文件上傳請求：將預(yù)置路徑的文件上傳至分布式文件系統(tǒng)；處理結(jié)果可以包括：完成上傳、上傳成功、或者上傳失敗等；

文件狀態(tài)查詢請求：查詢某個文件的文件狀態(tài)信息；處理結(jié)果可以為查詢得到的文件狀態(tài)信息；

文件下載請求：下載某個文件；處理結(jié)果可以為讀取得到的文件；

文件刪除請求：刪除某個文件；處理結(jié)果可以為刪除成功或者刪除失敗。

可以理解，上述文件處理請求只是作為可選實施例，實際上，本領(lǐng)域技術(shù)人員可以根據(jù)實際應(yīng)用需求，采用各種各樣的文件處理請求，本發(fā)明實施例對于具體的文件處理請求不加以限制。

在實際應(yīng)用中，可以針對每種文件處理請求設(shè)置對應(yīng)的API(應(yīng)用程序編程接口，Application Programming Interface)，并將所有的API接口集成在SDK(軟件開發(fā)工具包，Software Development Kit)中，以供客戶端調(diào)用，進(jìn)而產(chǎn)生對應(yīng)的文件處理請求。可選地，上述API接口可以基于HTTP(超文本傳輸協(xié)議，HyperText Transfer Protocol)協(xié)議，以供客戶端調(diào)用。

步驟102、對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

上述加鎖處理可以使得同一時刻僅有一個用戶訪問分布式文件，故能夠有效解決多用戶訪問帶來的訪問沖突問題，進(jìn)而有效保證分布式文件的一致性。

本發(fā)明實施例的鎖可以為分布式鎖，該分布式鎖可以具有高性能、避免死鎖、支持鎖重入等優(yōu)點，以使得該分布式鎖不會成為系統(tǒng)的性能瓶頸，且在獲得鎖的節(jié)點掛掉時不會導(dǎo)致其他節(jié)點永遠(yuǎn)無法繼續(xù)等。

在本發(fā)明的一種可選實施例中，可以通過ZooKeeper(動物管理員)對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖。ZooKeeper是一個分布式的、開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，其可以為分布式應(yīng)用提供一致性服務(wù)。ZooKeeper包含一個簡單的原語集，提供Java和C的接口。ZooKeeper的代碼版本中提供了分布式獨享鎖的接口。在本發(fā)明的一種應(yīng)用示例中，假設(shè)節(jié)點A請求加鎖，其經(jīng)ZooKeeper注冊得到ID1，并且，節(jié)點B請求加鎖，其經(jīng)ZooKeeper注冊得到ID2，則節(jié)點A可以獲取所有節(jié)點的ID，判斷出自身的ID最小，于是可以獲得鎖，而節(jié)點B可以獲取所有節(jié)點的ID，判斷出自身的ID不是最小的，于是監(jiān)聽ID小于自身ID的最大節(jié)點的變更事件；進(jìn)一步，假設(shè)節(jié)點A在拿到鎖后，進(jìn)行文件處理請求的處理，并在處理完成后釋放鎖，也即刪除自身節(jié)點；而節(jié)點B在接收到節(jié)點A的變更事件后，若判斷出自身的ID最小，則可以獲得鎖。其中，上述節(jié)點A、節(jié)點B可以為用于處理文件處理請求的節(jié)點。

在本發(fā)明的另一種可選實施例中，可以通過Redis對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖。Redis是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、key-Value(鍵值對)數(shù)據(jù)庫。在本發(fā)明的一種應(yīng)用示例中，可以使用setnx(key,時間戮超時)設(shè)置鎖，如果設(shè)置成功，則直接拿到鎖，如果設(shè)置不成功，則獲取key的值v1(它的到期時間戮)，將v1與當(dāng)前時間對比，看是否已經(jīng)超時，如果超時(說明拿到鎖的結(jié)點已經(jīng)掛掉)，v2＝getset(key,時間戮超時1)，判斷v2是否等于v1，如果相等，則加鎖成功，否則加鎖失敗，等過段時間(200MS)再重試。

可以理解，上述通過ZooKeeper或者Redis對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖的過程只是作為可選實施例，實際上，本領(lǐng)域技術(shù)人員可以根據(jù)實際應(yīng)用需求，采用所需的其他加鎖工具，如memcached等，memcached是分布式的高速緩存系統(tǒng)，其帶有add函數(shù)，可利用add函數(shù)的特性即可實現(xiàn)分布式鎖。

步驟103、從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息可以包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

本發(fā)明實施例中，第一分布式文件系統(tǒng)和第二分布式文件系統(tǒng)為不同的分布式文件系統(tǒng)，本領(lǐng)域技術(shù)人員可以根據(jù)實際應(yīng)用需求，選擇任意的兩種分布式文件系統(tǒng)作為第一分布式文件系統(tǒng)和第二分布式文件系統(tǒng)。例如，可以從GFS(google File System)、HBase(Hadoop Database)、HDFS、Lustre(Linux和Cluster的混成詞)、Ceph(Linux PB級分布式文件系統(tǒng))、GridFS(GridFS)、mogileFS(高效的文件自動備份組件)、TFS(Taobao FileSystem)、FastDFS等。

可選地，第一分布式文件系統(tǒng)和第二分布式文件系統(tǒng)可以屬于同一分布式系統(tǒng)基礎(chǔ)架構(gòu)，以提高分布式系統(tǒng)基礎(chǔ)架構(gòu)的性能，且還可以避免第一分布式文件系統(tǒng)和第二分布式文件系統(tǒng)與分布式系統(tǒng)基礎(chǔ)架構(gòu)之間出現(xiàn)兼容問題。例如，本發(fā)明實施例可以采用Hadoop的Hbase和HDFS作為第一分布式文件系統(tǒng)和第二分布式文件系統(tǒng)，具體地，可以將文件內(nèi)容存儲于HDFS內(nèi)部，以支持大文件和海量文件的存儲，同時，還可以將文件的基本信息存儲于Hbase。在本發(fā)明的一種應(yīng)用示例，假設(shè)需要存儲的文件數(shù)目為1500萬，假設(shè)每個文件的基本信息大小在1K以內(nèi)，則Hbase需要占用的存儲空間為15G左右；假設(shè)1500萬個文件文件內(nèi)容的大小為50T，則在默認(rèn)2份備份的情況下，HDFS需要占用的存儲空間為150T左右。

這樣，本發(fā)明實施例可以對海量文件進(jìn)行存儲的同時，通過Hadoop的MapReduce(映射化簡)進(jìn)行文件的全量和隨機(jī)回掃能力?，F(xiàn)有方案的HDFS通過文件列表枚舉方式獲取文件的特性導(dǎo)致其并不能實現(xiàn)隨機(jī)掃描，而現(xiàn)有的Hbase對數(shù)據(jù)訪問的耗時較長導(dǎo)致其全量掃描的耗時要在一周以上一個迭代，而本發(fā)明實施例可以同時具備快速全量和隨機(jī)回掃的能力?？梢岳斫猓谝环植际轿募到y(tǒng)和第二分布式文件系統(tǒng)屬于同一分布式系統(tǒng)基礎(chǔ)架構(gòu)只是作為可選實施例，實際上，不屬于同一分布式系統(tǒng)基礎(chǔ)架構(gòu)的第一分布式文件系統(tǒng)和第二分布式文件系統(tǒng)也在本發(fā)明實施例的保護(hù)范圍之內(nèi)。

在實際應(yīng)用中，待處理請求中可以攜帶待處理文件的信息，如文件主鍵(key)、文件名、文件的MD5(消息摘要算法第5版，Message Digest Algorithm 5)等，而第一分布式文件系統(tǒng)上存儲的基本信息中可以包括：文件主鍵(key)和文件在第二分布式文件系統(tǒng)上的存儲路徑等信息，由于一個文件通常具有唯一的key，這樣，可以依據(jù)待處理文件的文件主鍵從第一分布式文件系統(tǒng)上讀取待處理文件的其他基本信息，如文件在第二分布式文件系統(tǒng)上的存儲路徑、文件大小、文件名、文件狀態(tài)信息等信息等。需要說明的是，在待處理請求中攜帶待處理文件的文件名、文件的MD5等信息時，可以對這些信息進(jìn)行例如哈希運(yùn)算，以將這些信息轉(zhuǎn)換為文件主鍵，本發(fā)明實施例對于具體的轉(zhuǎn)換過程不加以限制。

步驟104、依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理。

本發(fā)明實施例中，待處理文件的基本信息可以作為文件處理請求的處理依據(jù)。例如，在文件處理請求為文件下載請求時，可以依據(jù)基本信息中的存儲路徑，從第二分布式文件系統(tǒng)上讀取所述待處理文件的文件內(nèi)容，并下載所述待處理文件的文件內(nèi)容。

可選地，在完成文件處理請求的處理后，可以對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行解鎖，以使得其他文件處理請求具備待處理文件所屬的文件目錄的訪問可能，可以理解，本發(fā)明實施例對于具體的解鎖過程和解鎖時機(jī)不加以限制。

綜上，本發(fā)明實施例的文件處理方法，當(dāng)存在對于文件的處理(如訪問)需求時，可以從第一分布式文件系統(tǒng)上獲取文件在第二分布式文件系統(tǒng)上的存儲路徑，相對于現(xiàn)有的HDFS是通過文件列表枚舉方式獲取文件，可以實現(xiàn)待處理文件的快速定位，因此可以提高文件的處理效率，進(jìn)而可以提高在線應(yīng)用程序的訪問性能。

參照圖2，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟201、接收文件下載請求；

步驟202、對所述文件下載請求對應(yīng)待下載文件所屬的文件目錄進(jìn)行加鎖；所述待下載文件的基本信息存儲于第一文件系統(tǒng)，所述待下載文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

步驟203、從第一分布式文件系統(tǒng)上讀取所述待下載文件的基本信息；所述基本信息可以包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

步驟204、依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上讀取所述待處理文件的文件內(nèi)容；

步驟205、下載所述待處理文件的文件內(nèi)容。

文件下載請求可用于下載某個key的文件，處理結(jié)果可以為讀取得到的文件，并將讀取得到的文件返回?？蛇x地，客戶端可以通過文件下載請求對應(yīng)的API接口產(chǎn)生上述文件下載請求。

在本發(fā)明的一種可選實施例中，在執(zhí)行步驟204之前，可以依據(jù)所述基本信息中的上傳完成標(biāo)識，判斷是否完成所述待下載文件的上傳，若是，則可以執(zhí)行步驟204，否則可以直接返回例如下載失敗、或者文件不存在的處理結(jié)果。例如，在接收到文件下載請求后，可以通過ZooKeeper對所述文件下載理請求對應(yīng)待下載文件所屬的文件目錄進(jìn)行加鎖，并從Hbase上讀取該待下載文件的文件在第二分布式文件系統(tǒng)上的存儲路徑、文件狀態(tài)信息等基本信息；進(jìn)一步，該文件狀態(tài)信息包括：上傳完成標(biāo)識，則可以依據(jù)所述基本信息中的上傳完成標(biāo)識，判斷是否完成所述待下載文件的上傳，若是，則可以執(zhí)行步驟204，否則可以返回例如下載失敗或者文件不存在的處理結(jié)果。上述依據(jù)基本信息中的上傳完成標(biāo)識進(jìn)行的判斷處理，能夠在待下載文件未上傳完成時快速地得到對應(yīng)的處理結(jié)果，因此能夠提高待下載請求的處理效率。

參照圖3，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟301、接收文件刪除請求；

步驟302、對所述文件刪除請求對應(yīng)待刪除文件所屬的文件目錄進(jìn)行加鎖；所述待刪除文件的基本信息存儲于第一文件系統(tǒng)，所述待刪除文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

步驟303、從第一分布式文件系統(tǒng)上讀取所述待刪除文件的基本信息；所述基本信息可以包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

步驟304、依據(jù)所述存儲路徑，在所述第二分布式文件系統(tǒng)上刪除所述待刪除文件的文件內(nèi)容；

步驟305、在所述第一分布式文件系統(tǒng)上刪除所述待刪除文件的基本信息。

文件刪除請求可用于刪除某個某個key對應(yīng)文件的存儲內(nèi)容(包括基本信息和文件內(nèi)容)，處理結(jié)果可以為刪除成功或者刪除失敗?？蛇x地，客戶端可以通過文件刪除請求對應(yīng)的API接口產(chǎn)生上述文件刪除請求。

在本發(fā)明的一種可選實施例中，當(dāng)無法從第一分布式文件系統(tǒng)上讀取所述待刪除文件的基本信息時，可以說明待刪除文件不存在，故可以直接得到例如刪除失敗的處理結(jié)果。

本發(fā)明實施例對于步驟304和步驟305的執(zhí)行順序不加以限制，也即，可以并列、先后或者后先執(zhí)行步驟304和步驟305。

參照圖4，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟401、接收文件狀態(tài)查詢請求；

步驟402、對所述文件狀態(tài)查詢請求對應(yīng)待查詢文件所屬的文件目錄進(jìn)行加鎖；所述待查詢文件的基本信息存儲于第一文件系統(tǒng)，所述待查詢文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

步驟403、從第一分布式文件系統(tǒng)上讀取所述待查詢文件的基本信息；所述基本信息可以包括：文件狀態(tài)信息；

步驟404、從所述待查詢文件的基本信息中獲取文件狀態(tài)信息，并將所述文件狀態(tài)信息作為處理結(jié)果返回。

文件狀態(tài)查詢請求可用于查詢某個key的文件狀態(tài)信息，處理結(jié)果可以為查詢得到的文件狀態(tài)信息?？蛇x地，客戶端可以通過文件狀態(tài)請求對應(yīng)的API接口產(chǎn)生上述文件狀態(tài)查詢請求。

在本發(fā)明的一種可選實施例中，上述文件狀態(tài)信息包括：處理狀態(tài)標(biāo)識、文件長度、上傳長度、上傳完成標(biāo)識和存儲偏移中的至少一種。其中，上述上傳完成標(biāo)識可用于表示是否完成文件的上傳，上述處理狀態(tài)標(biāo)識可用于表示文件的上傳、下載等處理過程中是否存在異常處理，可選地，上述上傳完成標(biāo)識和上述處理狀態(tài)標(biāo)識可采用true和false、或者1和0來表示對應(yīng)的狀態(tài)。文件長度可用于表示文件所占用的字節(jié)大小，上傳長度可用于表示上傳的文件所占用的字節(jié)大小，通常，上傳長度小于等于文件長度，存儲偏移可用于表示文件所對應(yīng)數(shù)據(jù)塊的地址偏移量?？梢岳斫?，可用于表征文件狀態(tài)的任意文件狀態(tài)信息均在本發(fā)明實施例的保護(hù)范圍之內(nèi)。

參照圖5，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟501、接收文件上傳請求；

步驟502、對所述文件上傳請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

步驟503、從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息可以包括：上傳完成標(biāo)識和文件在第二分布式文件系統(tǒng)上的存儲路徑；

步驟504、依據(jù)所述基本信息中的上傳完成標(biāo)識，判斷是否完成所述待處理文件的上傳；

步驟505、當(dāng)確定完成所述待處理文件的上傳時，返回完成上傳的處理結(jié)果。

文件上傳請求可用于將預(yù)置路徑的文件上傳至分布式文件系統(tǒng)中key的位置，處理結(jié)果可以包括：完成上傳、上傳成功、或者上傳失敗等?？蛇x地，客戶端可以通過文件上傳請求對應(yīng)的API接口產(chǎn)生上述文件上傳請求。

本發(fā)明實施例可以依據(jù)基本信息中的上傳完成標(biāo)識，判斷是否完成所述待處理文件的上傳，若是，則說明待處理文件已經(jīng)存在于分布式文件系統(tǒng)，故可以直接得到完成上傳的處理結(jié)果；相對于傳統(tǒng)方案將預(yù)置路徑的待處理文件寫入第二分布式文件系統(tǒng)，本發(fā)明實施例基于上傳完成標(biāo)識的處理能夠提高文件上傳請求的處理效率。

在本發(fā)明的一種可選實施例中，所述基本信息還可以包括：處理狀態(tài)標(biāo)識，上述方法還可以包括：當(dāng)確定未完成所述待處理文件的上傳時，依據(jù)所述基本信息中的處理狀態(tài)標(biāo)識判斷所述待處理文件是否存在處理異常；當(dāng)確定所述待處理文件存在處理異常時，在第二文件系統(tǒng)上進(jìn)行所述待處理文件的異常處理；在完成所述異常處理后，依據(jù)所述待處理文件在第二文件系統(tǒng)上的存儲狀態(tài)判斷所述待處理文件是否被成功上傳；當(dāng)確定所述待處理文件被成功上傳時，返回成功上傳的處理結(jié)果。本可選實施例可以進(jìn)一步依據(jù)基本信息中的處理狀態(tài)標(biāo)識判斷待處理文件是否存在處理異常，若是，則在第二文件系統(tǒng)上進(jìn)行所述待處理文件的異常修復(fù)，并在完成異常修復(fù)后進(jìn)一步判斷待處理文件是否被成功上傳，若是，則返回成功上傳的處理結(jié)果。相對于傳統(tǒng)方案將預(yù)置路徑的待處理文件寫入第二分布式文件系統(tǒng)，本發(fā)明實施例基于處理狀態(tài)標(biāo)識和異常修復(fù)的處理，能夠在待處理文件的已有異常處理的基礎(chǔ)上進(jìn)行異常處理(例如斷點續(xù)傳、或者文件修復(fù)等)，因此能夠提高文件上傳請求的處理效率。

在本發(fā)明的另一種可選實施例中，上述方法還可以包括：當(dāng)確定所述待處理文件不存在處理異常、或者確定所述待處理文件未被成功上傳時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。上述處理不僅能夠?qū)⒋幚砦募懭胨龅诙募到y(tǒng)，而且能夠及時地更新處理狀態(tài)標(biāo)識。

在本發(fā)明的再一種可選實施例中，上述方法還可以包括：當(dāng)?shù)谝环植际轿募到y(tǒng)上不存在所述待處理文件的基本信息時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。上述處理不僅能夠?qū)⒋幚砦募懭胨龅诙募到y(tǒng)，而且能夠及時地更新處理狀態(tài)標(biāo)識。

參照圖6，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟601、接收文件上傳請求；

步驟602、對所述文件上傳請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

步驟603、判斷第一文件系統(tǒng)上是否存在所述待處理文件的基本信息，若是，則執(zhí)行步驟604，否則執(zhí)行步驟608；

步驟604、依據(jù)所述基本信息中的上傳完成標(biāo)識判斷是否完成所述待上傳文件的上傳，若是，則執(zhí)行步驟609，否則執(zhí)行步驟605；

步驟605、當(dāng)確定未完成所述待處理文件的上傳時，依據(jù)所述基本信息中的處理狀態(tài)標(biāo)識判斷所述待處理文件是否存在處理異常，若是，則執(zhí)行步驟606，否則執(zhí)行步驟608；

步驟606、當(dāng)確定所述待處理文件存在處理異常時，在第二文件系統(tǒng)上進(jìn)行所述待處理文件的異常處理；

步驟607、在完成所述異常處理后，依據(jù)所述待處理文件在第二文件系統(tǒng)上的存儲狀態(tài)判斷所述待處理文件是否被成功上傳，若是，則執(zhí)行步驟609，否則執(zhí)行步驟608；

步驟608、當(dāng)?shù)谝环植际轿募到y(tǒng)上不存在所述待處理文件的基本信息、或者確定所述待處理文件不存在處理異常、或者確定所述待處理文件未被成功上傳時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果；

步驟609、返回完成上傳的處理結(jié)果；

步驟610、對所述待處理文件所屬的文件目錄進(jìn)行解鎖。

參照圖7，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟701、接收文件處理請求；

步驟702、對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

步驟703、從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

步驟704、依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理；

相對于圖1至圖6中任一的實施例，本實施例的方法還可以包括：

步驟705、接收隨機(jī)掃描請求；所述隨機(jī)掃描請求中攜帶有需要隨機(jī)掃描的主鍵；

步驟706、從第一分布式文件系統(tǒng)上讀取所述需要隨機(jī)掃描的主鍵對應(yīng)文件在第二分布式文件系統(tǒng)上的存儲路徑；

步驟707、依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上獲取所述需要隨機(jī)掃描的主鍵對應(yīng)文件的文件內(nèi)容；

步驟708、利用掃描工具進(jìn)行所獲取文件內(nèi)容的掃描。

現(xiàn)有方案的HDFS通過文件列表枚舉方式獲取文件的特性導(dǎo)致其并不能實現(xiàn)隨機(jī)掃描，而現(xiàn)有的Hbase對數(shù)據(jù)訪問的耗時較長導(dǎo)致其全量掃描的耗時要在一周以上一個迭代。

而本發(fā)明實施例將文件的基本信息和文件內(nèi)容分開存儲，基本信息通過例如Hbase的第一分布式文件系統(tǒng)存儲，隨機(jī)掃描時快速根據(jù)key獲取文件在例如HDFS的第二分布式文件系統(tǒng)上的存儲路徑，然后通過回掃框架包(JAR)中原生的API接口進(jìn)行文件內(nèi)容的獲取，最后通過第三方掃描工具對文件內(nèi)容的掃描。另外，本發(fā)明的回掃框架，可以將第三方掃描工具通過參數(shù)傳遞給框架，用戶可以不修改框架的任何代碼，即可通過第三方掃描工具實現(xiàn)對所存儲文件的隨機(jī)掃描。其中，該回掃框架包中可以包括定制化的參數(shù)。

可以理解，除了隨機(jī)掃描外，本發(fā)明實施例還可以實現(xiàn)對于所存儲文件的全量掃描。在本發(fā)明的一種應(yīng)用示例中，假設(shè)所存儲文件的數(shù)量1500萬以上，所存儲文件的總大小為50T，所存儲文件的平均大小為3.5M，假設(shè)掃描需求如下：每日有訓(xùn)練算法的全量掃描，以找出特異結(jié)果樣本；不定期有第三方掃描器的隨機(jī)回掃，找出第三方掃描器和自身的差別；訓(xùn)練算法更改或優(yōu)化時，可以快速全量掃描，以得到改進(jìn)或優(yōu)化結(jié)果，進(jìn)行對比。應(yīng)用本發(fā)明實施例，全量掃描所耗費的時間為4個小時左右，相對于現(xiàn)有方案中一周以上的耗時，能夠大大提高全量掃描的效率。

參照圖8，示出了根據(jù)本發(fā)明一個實施例的一種文件處理方法的步驟流程圖，具體可以包括如下步驟：

步驟801、接收文件處理請求；

步驟802、對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

步驟803、從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

步驟804、依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理；

相對于圖1至圖6中任一的實施例，本實施例的方法還可以包括：

步驟805、定期對新增存儲的文件進(jìn)行合并操作。

現(xiàn)有方案中HDFS的名稱節(jié)點將所存儲文件的元數(shù)據(jù)存放在內(nèi)存中，導(dǎo)致存儲的文件數(shù)目受限于名稱節(jié)點的內(nèi)存大小。假設(shè)HDFS中每個文件、目錄、數(shù)據(jù)塊占用150Bytes，則如果存放1million數(shù)目的文件至少消耗300MB內(nèi)存，如果要存放1billion的數(shù)目的文件將會超出硬件能力，因此，HDFS不適合大量小文件的存儲。

為了減少HDFS中小文件的數(shù)量，本發(fā)明實施例還可以將新增存儲的文件合并到大文件中。具體地，對于新增存儲的文件采取臨時存放的策略，在每小時的合并階段，將臨時存放的文件合并到對應(yīng)的大文件中。例如，新增存儲目錄放在xstore/bucket這一臨時存儲目錄下，合并后的大文件放在xstore_merge/bucket這一合并存儲目錄下。

在實際應(yīng)用中，可以針對一個bucket(桶)設(shè)置臨時存儲目錄和合并存儲目錄；每個目錄下面可根據(jù)參數(shù)配置劃分成16^n個目錄，n默認(rèn)為3，此參數(shù)影響hadoop合并任務(wù)的最大worker(工人)數(shù)。在將新增存儲的文件進(jìn)行合并操作的過程中，可以對會對臨時存儲目錄的文件進(jìn)行枚舉，逐個進(jìn)行文件的移動，具體地，將新增存儲的文件對應(yīng)的key取哈希值，并將哈希結(jié)果作為合并存儲目錄的子目錄最后一節(jié)。

假設(shè)新增存儲的文件的key為154712366.sandbox和154717588.sandbox，經(jīng)過上傳接口存儲到以下HDFS的臨時存儲目錄：

xstore/bucket***/c69/154712366.sandbox

xstore/bucket***/c69/154717588.sandbox

則在進(jìn)行合并操作的過程中，可以對會對臨時存儲目錄的文件進(jìn)行枚舉，逐個將文件append(追加)到對應(yīng)key的大文件里，同時對臨時存儲目錄的文件key在Hbase存儲的基本信息進(jìn)行修改，例如，將上述兩個文件合并后的HDFS存儲目錄可以：

xstore_merge/bucket***/c69/.sn

xstore_merge/bucket***/c69/000.mrg

xstore_merge/bucket***/c69/001.mrg

xstore_merge/bucket***/c69/002.mrg

xstore_merge/bucket***/c69/003.mrg

xstore_merge/bucket***/c69/004.mrg

上述合并存儲目錄的子目錄，是按照序號.sn遞增，每次合并將新增文件append到最大序號文件，如004.mrg。

綜上，本發(fā)明實施例將文件內(nèi)容存儲于第二分布式文件系統(tǒng)，支持大文件和海量文件；同時將文件的基本信息存儲于第一分布式文件系統(tǒng)；與現(xiàn)有的HDFS相比，本發(fā)明實施例具有如下優(yōu)點：

首先，可以在對海量文件進(jìn)行存儲的同時，可以通過MapReduce進(jìn)行文件的全量和隨機(jī)掃描能力；

其次，可以提供一套通用的基于Streaming(流)方式的回掃框架，支持第三方的掃描工具的嵌入；

再者，可以提供一套基于HTTP協(xié)議的服務(wù)端接口，內(nèi)部使用分布式鎖解決高并發(fā)的訪問沖突問題，供客戶端的調(diào)用；

此外，對于第二分布式文件系統(tǒng)存儲的文件，可以通過合并使文件數(shù)目符合收縮文件數(shù)目，解決HDFS中下文件過多造成系統(tǒng)瓶頸的問題。

另外，相對于現(xiàn)有的HDFS通過文件列表枚舉方式獲取文件，對于文件狀態(tài)查詢、文件下載、文件上傳、文件刪除等文件處理請求，可以通過第一文件系統(tǒng)上存儲的基本信息進(jìn)行文件的快速定位，因此能夠提高文件處理效率。

對于方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領(lǐng)域技術(shù)人員應(yīng)該知悉，本發(fā)明實施例并不受所描述的動作順序的限制，因為依據(jù)本發(fā)明實施例，某些步驟可以采用其他順序或者同時進(jìn)行。其次，本領(lǐng)域技術(shù)人員也應(yīng)該知悉，說明書中所描述的實施例均屬于可選實施例，所涉及的動作并不一定是本發(fā)明實施例所必須的。

參照圖9，示出了根據(jù)本發(fā)明一個實施例的一種文件處理裝置的結(jié)構(gòu)框圖，具體可以包括如下模塊：

請求接收模塊901，用于接收文件處理請求；

目錄加鎖模塊902，用于對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

信息獲取模塊903，用于從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息具體可以包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

請求處理模塊904，用于依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理。

可選地，所述文件處理請求具體可以包括：文件下載請求，所述請求處理模塊904具體可以包括：

文件內(nèi)容讀取子模塊，用于依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上讀取所述待處理文件的文件內(nèi)容；

文件內(nèi)容下載子模塊，用于下載所述待處理文件的文件內(nèi)容。

可選地，所述文件處理請求具體可以包括：文件刪除請求，所述請求處理模塊904具體可以包括：

第一刪除子模塊，用于依據(jù)所述存儲路徑，在所述第二分布式文件系統(tǒng)上刪除所述待處理文件的文件內(nèi)容；

第二刪除子模塊，用于在所述第一分布式文件系統(tǒng)上刪除所述待處理文件的基本信息。

可選地，所述文件處理請求具體可以包括：文件狀態(tài)查詢請求，所述基本信息還可以包括文件狀態(tài)信息，所述請求處理模塊904包括：

狀態(tài)信息處理子模塊，用于從所述待處理文件的基本信息中獲取文件狀態(tài)信息，并將所述文件狀態(tài)信息作為處理結(jié)果返回。

可選地，所述文件處理請求可以包括：文件上傳請求，所述基本信息還可以包括：上傳完成標(biāo)識，所述請求處理模塊904具體可以包括：

第一判斷子模塊，用于依據(jù)所述基本信息中的上傳完成標(biāo)識，判斷是否完成所述待處理文件的上傳；

第一結(jié)果返回子模塊，用于當(dāng)確定完成所述待處理文件的上傳時，返回完成上傳的處理結(jié)果。

可選地，所述基本信息還可以包括：處理狀態(tài)標(biāo)識，所述請求處理模塊904還可以包括：

第二判斷子模塊，用于當(dāng)確定未完成所述待處理文件的上傳時，依據(jù)所述基本信息中的處理狀態(tài)標(biāo)識判斷所述待處理文件是否存在處理異常；

異常處理子模塊，用于當(dāng)確定所述待處理文件存在處理異常時，在第二文件系統(tǒng)上進(jìn)行所述待處理文件的異常處理；

第三判斷子模塊，用于在完成所述異常處理后，依據(jù)所述待處理文件在第二文件系統(tǒng)上的存儲狀態(tài)判斷所述待處理文件是否被成功上傳；

第二結(jié)果返回子模塊，用于當(dāng)確定所述待處理文件被成功上傳時，返回成功上傳的處理結(jié)果。

可選地，所述請求處理模塊904還可以包括：

第一寫入處理子模塊，用于當(dāng)確定所述待處理文件不存在處理異常、或者確定所述待處理文件未被成功上傳時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

第三結(jié)果返回子模塊，用于在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

可選地，所述裝置還可以包括：

第二寫入處理子模塊，用于當(dāng)?shù)谝环植际轿募到y(tǒng)上不存在所述待處理文件的基本信息時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

第四結(jié)果返回子模塊，用于在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

可選地，所述裝置還可以包括：

掃描請求接收模塊，用于接收隨機(jī)掃描請求；所述隨機(jī)掃描請求中攜帶有需要隨機(jī)掃描的主鍵；

路徑讀取模塊，用于從第一分布式文件系統(tǒng)上讀取所述需要隨機(jī)掃描的主鍵對應(yīng)文件在第二分布式文件系統(tǒng)上的存儲路徑；

文件內(nèi)容讀取模塊，用于依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上獲取所述需要隨機(jī)掃描的主鍵對應(yīng)文件的文件內(nèi)容；

掃描模塊，用于利用掃描工具進(jìn)行所獲取文件內(nèi)容的掃描。

可選地，所述裝置還可以包括：

文件合并模塊，用于定期對新增存儲的文件進(jìn)行合并操作。

對于裝置實施例而言，由于其與方法實施例基本相似，所以描述的比較簡單，相關(guān)之處參見方法實施例的部分說明即可。

在此提供的算法和顯示不與任何特定計算機(jī)、虛擬系統(tǒng)或者其它設(shè)備固有相關(guān)。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據(jù)上面的描述，構(gòu)造這類系統(tǒng)所要求的結(jié)構(gòu)是顯而易見的。此外，本發(fā)明也不針對任何特定編程語言。應(yīng)當(dāng)明白，可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內(nèi)容，并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細(xì)節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細(xì)節(jié)的情況下實踐。在一些實例中，并未詳細(xì)示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對本說明書的理解。

類似地，應(yīng)當(dāng)理解，為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個，在上面對本發(fā)明的示例性實施例的描述中，本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應(yīng)將該公開的方法解釋成反映如下意圖：即所要求保護(hù)的本發(fā)明要求比在每個權(quán)利要求中所明確記載的特征更多的特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此，遵循具體實施方式的權(quán)利要求書由此明確地并入該具體實施方式，其中每個權(quán)利要求本身都作為本發(fā)明的單獨實施例。

本領(lǐng)域那些技術(shù)人員可以理解，可以對實施例中的設(shè)備中的模塊進(jìn)行自適應(yīng)性地改變并且把它們設(shè)置在與該實施例不同的一個或多個設(shè)備中。可以把實施例中的模塊或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設(shè)備的所有過程或單元進(jìn)行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領(lǐng)域的技術(shù)人員能夠理解，盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實施例。例如，在下面的權(quán)利要求書中，所要求保護(hù)的實施例的任意之一都可以以任意的組合方式來使用。

本發(fā)明的各個部件實施例可以以硬件實現(xiàn)，或者以在一個或者多個處理器上運(yùn)行的軟件模塊實現(xiàn)，或者以它們的組合實現(xiàn)。本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，可以在實踐中使用微處理器或者數(shù)字信號處理器(DSP)來實現(xiàn)根據(jù)本發(fā)明實施例的文件處理方法和裝置中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設(shè)備或者裝置程序(例如，計算機(jī)程序和計算機(jī)程序產(chǎn)品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機(jī)可讀介質(zhì)上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網(wǎng)平臺上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應(yīng)該注意的是上述實施例對本發(fā)明進(jìn)行說明而不是對本發(fā)明進(jìn)行限制，并且本領(lǐng)域技術(shù)人員在不脫離所附權(quán)利要求的范圍的情況下可設(shè)計出替換實施例。在權(quán)利要求中，不應(yīng)將位于括號之間的任何參考符號構(gòu)造成對權(quán)利要求的限制。單詞“包括”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當(dāng)編程的計算機(jī)來實現(xiàn)。在列舉了若干裝置的單元權(quán)利要求中，這些裝置中的若干個可以是通過同一個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序?？蓪⑦@些單詞解釋為名稱。

本發(fā)明公開了A1、一種文件處理方法，包括：

接收文件處理請求；

對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理。

A2、如A1所述的方法，所述文件處理請求包括：文件下載請求，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上讀取所述待處理文件的文件內(nèi)容；

下載所述待處理文件的文件內(nèi)容。

A3、如A1所述的方法，所述文件處理請求包括：文件刪除請求，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

依據(jù)所述存儲路徑，在所述第二分布式文件系統(tǒng)上刪除所述待處理文件的文件內(nèi)容；

在所述第一分布式文件系統(tǒng)上刪除所述待處理文件的基本信息。

A4、如A1所述的方法，所述文件處理請求包括：文件狀態(tài)查詢請求，所述基本信息還包括文件狀態(tài)信息，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

從所述待處理文件的基本信息中獲取文件狀態(tài)信息，并將所述文件狀態(tài)信息作為處理結(jié)果返回。

A5、如A1所述的方法，所述文件處理請求包括：文件上傳請求，所述基本信息還包括：上傳完成標(biāo)識，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，包括：

依據(jù)所述基本信息中的上傳完成標(biāo)識，判斷是否完成所述待處理文件的上傳；

當(dāng)確定完成所述待處理文件的上傳時，返回完成上傳的處理結(jié)果。

A6、如A5所述的方法，所述基本信息還包括：處理狀態(tài)標(biāo)識，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，還包括：

當(dāng)確定未完成所述待處理文件的上傳時，依據(jù)所述基本信息中的處理狀態(tài)標(biāo)識判斷所述待處理文件是否存在處理異常；

當(dāng)確定所述待處理文件存在處理異常時，在第二文件系統(tǒng)上進(jìn)行所述待處理文件的異常處理；

在完成所述異常處理后，依據(jù)所述待處理文件在第二文件系統(tǒng)上的存儲狀態(tài)判斷所述待處理文件是否被成功上傳；

當(dāng)確定所述待處理文件被成功上傳時，返回成功上傳的處理結(jié)果。

A7、如A6所述的方法，所述依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理的步驟，還包括：

當(dāng)確定所述待處理文件不存在處理異常、或者確定所述待處理文件未被成功上傳時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

A8、如A5所述的方法，所述方法還包括：

當(dāng)?shù)谝环植际轿募到y(tǒng)上不存在所述待處理文件的基本信息時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

A9、如A1至A8中任一所述的方法，所述方法還包括：

接收隨機(jī)掃描請求；所述隨機(jī)掃描請求中攜帶有需要隨機(jī)掃描的主鍵；

從第一分布式文件系統(tǒng)上讀取所述需要隨機(jī)掃描的主鍵對應(yīng)文件在第二分布式文件系統(tǒng)上的存儲路徑；

依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上獲取所述需要隨機(jī)掃描的主鍵對應(yīng)文件的文件內(nèi)容；

利用掃描工具進(jìn)行所獲取文件內(nèi)容的掃描。

A10、如A1至A8中任一所述的方法，所述方法還包括：

定期對新增存儲的文件進(jìn)行合并操作。

本發(fā)明還公開了B11、一種文件處理裝置，包括：

請求接收模塊，用于接收文件處理請求；

目錄加鎖模塊，用于對所述文件處理請求對應(yīng)待處理文件所屬的文件目錄進(jìn)行加鎖；所述待處理文件的基本信息存儲于第一文件系統(tǒng)，所述待處理文件的文件內(nèi)容存儲于第二文件系統(tǒng)；

信息獲取模塊，用于從第一分布式文件系統(tǒng)上讀取所述待處理文件的基本信息；所述基本信息包括：文件在第二分布式文件系統(tǒng)上的存儲路徑；

請求處理模塊，用于依據(jù)所述待處理文件的基本信息，對所述文件處理請求進(jìn)行處理。

B12、如B11所述的裝置，所述文件處理請求包括：文件下載請求，所述請求處理模塊包括：

文件內(nèi)容讀取子模塊，用于依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上讀取所述待處理文件的文件內(nèi)容；

文件內(nèi)容下載子模塊，用于下載所述待處理文件的文件內(nèi)容。

B13、如B11所述的裝置，所述文件處理請求包括：文件刪除請求，所述請求處理模塊包括：

第一刪除子模塊，用于依據(jù)所述存儲路徑，在所述第二分布式文件系統(tǒng)上刪除所述待處理文件的文件內(nèi)容；

第二刪除子模塊，用于在所述第一分布式文件系統(tǒng)上刪除所述待處理文件的基本信息。

B14、如B11所述的裝置，所述文件處理請求包括：文件狀態(tài)查詢請求，所述基本信息還包括文件狀態(tài)信息，所述請求處理模塊包括：

狀態(tài)信息處理子模塊，用于從所述待處理文件的基本信息中獲取文件狀態(tài)信息，并將所述文件狀態(tài)信息作為處理結(jié)果返回。

B15、如B11所述的裝置，所述文件處理請求包括：文件上傳請求，所述基本信息還包括：上傳完成標(biāo)識，所述請求處理模塊包括：

第一判斷子模塊，用于依據(jù)所述基本信息中的上傳完成標(biāo)識，判斷是否完成所述待處理文件的上傳；

第一結(jié)果返回子模塊，用于當(dāng)確定完成所述待處理文件的上傳時，返回完成上傳的處理結(jié)果。

B16、如B15所述的裝置，所述基本信息還包括：處理狀態(tài)標(biāo)識，所述請求處理模塊還包括：

第二判斷子模塊，用于當(dāng)確定未完成所述待處理文件的上傳時，依據(jù)所述基本信息中的處理狀態(tài)標(biāo)識判斷所述待處理文件是否存在處理異常；

異常處理子模塊，用于當(dāng)確定所述待處理文件存在處理異常時，在第二文件系統(tǒng)上進(jìn)行所述待處理文件的異常處理；

第三判斷子模塊，用于在完成所述異常處理后，依據(jù)所述待處理文件在第二文件系統(tǒng)上的存儲狀態(tài)判斷所述待處理文件是否被成功上傳；

第二結(jié)果返回子模塊，用于當(dāng)確定所述待處理文件被成功上傳時，返回成功上傳的處理結(jié)果。

B17、如B16所述的裝置，所述請求處理模塊還包括：

第一寫入處理子模塊，用于當(dāng)確定所述待處理文件不存在處理異常、或者確定所述待處理文件未被成功上傳時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

第三結(jié)果返回子模塊，用于在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

B18、如B15所述的裝置，所述裝置還包括：

第二寫入處理子模塊，用于當(dāng)?shù)谝环植际轿募到y(tǒng)上不存在所述待處理文件的基本信息時，將所述基本信息中的處理狀態(tài)標(biāo)識置為異常，將所述待處理文件寫入所述第二文件系統(tǒng)，并在成功寫入后將所述基本信息中的處理狀態(tài)標(biāo)識置為正常；

第四結(jié)果返回子模塊，用于在將所述基本信息中的處理狀態(tài)標(biāo)識置為正常后，返回成功上傳的處理結(jié)果。

B19、如B11至B18中任一所述的裝置，所述裝置還包括：

掃描請求接收模塊，用于接收隨機(jī)掃描請求；所述隨機(jī)掃描請求中攜帶有需要隨機(jī)掃描的主鍵；

路徑讀取模塊，用于從第一分布式文件系統(tǒng)上讀取所述需要隨機(jī)掃描的主鍵對應(yīng)文件在第二分布式文件系統(tǒng)上的存儲路徑；

文件內(nèi)容讀取模塊，用于依據(jù)所述存儲路徑，從所述第二分布式文件系統(tǒng)上獲取所述需要隨機(jī)掃描的主鍵對應(yīng)文件的文件內(nèi)容；

掃描模塊，用于利用掃描工具進(jìn)行所獲取文件內(nèi)容的掃描。

B20、如B11至B18中任一所述的裝置，所述裝置還包括：

文件合并模塊，用于定期對新增存儲的文件進(jìn)行合并操作。