本發(fā)明涉及分布式云存儲領(lǐng)域，特別涉及一種基于cifs協(xié)議創(chuàng)建小文件的方法及系統(tǒng)。

背景技術(shù)：

在分布式云存儲領(lǐng)域，云存儲系統(tǒng)服務(wù)端一般帶有元數(shù)據(jù)軟件用來統(tǒng)一管理文件系統(tǒng)的元數(shù)據(jù)信息。隨著文件數(shù)目和客戶端的增多，服務(wù)端需要管理很多文件的狀態(tài)、鎖等信息，這會導(dǎo)致客戶端創(chuàng)建文件時open調(diào)用返回慢，時延波動很大。為了解決這種問題，目前已經(jīng)有了很大方式來解決海量文件的管理問題，比如創(chuàng)建元數(shù)據(jù)服務(wù)端集群等，但是由于分布式文件系統(tǒng)軟件、硬件、網(wǎng)絡(luò)比較復(fù)雜，open調(diào)用時延高的情況很難避免。

現(xiàn)有技術(shù)中，基于cifs協(xié)議的軟件(例如，samba軟件)通過調(diào)用lib庫與后端的的分布式文件系統(tǒng)通信，并對外提供cifs協(xié)議，客戶端(例如，windows客戶端)通過cifs協(xié)議掛載導(dǎo)出的文件系統(tǒng)。由于此類基于cifs協(xié)議的軟件均是單線程架構(gòu)，如果后端的open接口時延波動很大，則會造成客戶端創(chuàng)建文件很慢或者卡頓。

因此，如何解決創(chuàng)建文件時因為open調(diào)用時延較長導(dǎo)致后續(xù)的其他請求卡住的問題，提高基于cifs協(xié)議創(chuàng)建小文件的性能成為了當(dāng)前需要解決的問題。

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

有鑒于此，本發(fā)明的目的在于提供一種基于cifs協(xié)議創(chuàng)建小文件的方法及系統(tǒng)，以解決創(chuàng)建文件時因為open調(diào)用時延較長導(dǎo)致后續(xù)的其他請求卡住的問題，提高基于cifs協(xié)議創(chuàng)建小文件的效率。其具體方案如下：

一種基于cifs協(xié)議創(chuàng)建小文件的方法，包括：

間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程；

利用所述主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，以使所述子線程集中接收open事件的子線程完成對open事件的處理，其中，空閑子線程為沒有正在處理open事件的子線程。

可選的，所述間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程的過程，包括：

利用所述主線程發(fā)送的open處理判斷結(jié)果，間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程，其中，所述open處理判斷結(jié)果為所述主線程判斷是否在預(yù)設(shè)時間內(nèi)接收到子線程發(fā)送的open處理結(jié)果的判斷結(jié)果。

可選的，所述利用所述主線程發(fā)送的open處理判斷結(jié)果，間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程的過程，包括：

利用所述主線程發(fā)送的open處理判斷超時結(jié)果，生成創(chuàng)建文件請求失敗記錄，利用所述創(chuàng)建文件請求失敗記錄，間斷的逐個發(fā)送所述創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至所述主線程。

可選的，所述利用所述創(chuàng)建文件請求失敗記錄，間斷的逐個發(fā)送所述創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至所述主線程的過程，包括：

利用所述創(chuàng)建文件請求失敗記錄，在所述創(chuàng)建文件請求集中的創(chuàng)建請求均發(fā)送過所述主線程后，間斷的逐個發(fā)送創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至所述主線程。

可選的，所述利用所述創(chuàng)建文件請求失敗記錄，間斷的逐個發(fā)送所述創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至所述主線程的過程，包括：

利用所述創(chuàng)建文件請求失敗記錄，在每發(fā)送預(yù)設(shè)閾值未發(fā)送過所述主線程的創(chuàng)建文件請求后，發(fā)送一個所述創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至所述主線程。

可選的，所述利用所述主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程之前，還包括：

利用所述主線程判斷與創(chuàng)建文件請求相應(yīng)的open事件是否發(fā)送到子線程集中的空閑子線程；

如果已發(fā)送，則不再利用所述主線程向所述子線程集中的空閑子線程發(fā)送open事件。

一種基于cifs協(xié)議創(chuàng)建小文件的系統(tǒng)，包括：

創(chuàng)建請求發(fā)送模塊，用于間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程；

open事件發(fā)送模塊，用于利用所述主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，以使所述子線程集中接收open事件的子線程完成對open事件的處理，其中，空閑子線程為沒有正在處理open事件的子線程。

可選的，所述創(chuàng)建請求發(fā)送模塊，具體用于利用所述主線程發(fā)送的open處理判斷結(jié)果，間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程，其中，所述open處理判斷結(jié)果為所述主線程判斷是否在預(yù)設(shè)時間內(nèi)接收到子線程發(fā)送的open處理結(jié)果的判斷結(jié)果。

可選的，所述創(chuàng)建請求發(fā)送模塊，包括：

失敗請求發(fā)送單元，用于利用所述主線程發(fā)送的open處理判斷超時結(jié)果，生成創(chuàng)建文件請求失敗記錄，利用所述創(chuàng)建文件請求失敗記錄，間斷的逐個發(fā)送所述創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至所述主線程。

可選的，還包括：

重復(fù)發(fā)送判斷模塊，用于利用所述主線程判斷與創(chuàng)建文件請求相應(yīng)的open事件是否發(fā)送到子線程集中的空閑子線程；

事件發(fā)送終止模塊，用于所述重復(fù)發(fā)送判斷模塊判定與創(chuàng)建文件請求相應(yīng)的open事件已發(fā)送到子線程集中的空閑子線程，則不再利用所述主線程向所述子線程集中的空閑子線程發(fā)送open事件。

本發(fā)明中，基于cifs協(xié)議創(chuàng)建小文件的方法，間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程；利用主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，以使子線程集中接收open事件的子線程完成對open事件的處理，其中，空閑子線程為沒有正在處理open事件的子線程。

本發(fā)明客戶端在間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程后，主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，而主線程本身不再進行open事件的處理，由子線程集中的多個空閑子線程分別處理不同創(chuàng)建文件請求相應(yīng)的open事件，因此即使一個open事件在一個子線程中處理緩慢，也不會影響主線程繼續(xù)接收客戶端發(fā)送創(chuàng)建文件請求和其余子線程并行異步處理其他open事件的進度，解決創(chuàng)建文件時因為open調(diào)用時延較長導(dǎo)致后續(xù)的其他請求卡住的問題，從而提高了基于cifs協(xié)議下創(chuàng)建小文件的效率。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)提供的附圖獲得其他的附圖。

圖1為本發(fā)明實施例公開的一種基于cifs協(xié)議創(chuàng)建小文件的方法流程示意圖；

圖2為本發(fā)明實施例公開的另一種基于cifs協(xié)議創(chuàng)建小文件的方法流程示意圖；

圖3為本發(fā)明實施例公開的一種基于cifs協(xié)議創(chuàng)建小文件的系統(tǒng)結(jié)構(gòu)示意圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

本發(fā)明實施例公開了一種基于cifs協(xié)議創(chuàng)建小文件的方法，參見圖1所示，該方法包括：

步驟s11：間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程；

具體的，每當(dāng)主線程處理完一個創(chuàng)建文件請求后，客戶端中的基于cifs協(xié)議的軟件才會再次發(fā)送創(chuàng)建文件請求至主線程，形成間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程。

步驟s12：利用主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，以使子線程集中接收open事件的子線程完成對open事件的處理，其中，空閑子線程為沒有正在處理open事件的子線程。

具體的，主線程在接收到客戶端發(fā)送的創(chuàng)建文件請求后，利用創(chuàng)建文件請求將其中的open事件發(fā)送到子線程集中的空閑子線程，由多個子線程并行異步處理不同創(chuàng)建文件請求對應(yīng)的open事件，只有子線程處于空閑狀態(tài)時才會接受open事件，一旦子線程接收到主線程發(fā)送的open事件并進行處理，就不再處于空閑狀態(tài)，主線程也不會再將open事件發(fā)送給不處于空閑狀態(tài)的空閑子線程，即，一個子線程在處理完一個open事件之前不會接收和處理另一個open事件，但當(dāng)子線程處理完當(dāng)前open事件，子線程就會變?yōu)榭臻e子線程，便可以繼續(xù)接收主線程發(fā)送的open事件。

需要說明的是，即使主線程結(jié)束與open事件相應(yīng)的創(chuàng)建文件請求，子線程也將繼續(xù)處理相應(yīng)的open事件，直至處理完成。

可見，本發(fā)明實施例客戶端在間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程后，主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，而主線程本身不再進行open事件的處理，由子線程集中的多個空閑子線程分別處理不同創(chuàng)建文件請求相應(yīng)的open事件，因此即使一個open事件在一個子線程中處理緩慢，也不會影響主線程繼續(xù)接收客戶端發(fā)送創(chuàng)建文件請求和其余子線程并行異步處理其他open事件的進度，解決創(chuàng)建文件時因為open調(diào)用時延較長導(dǎo)致后續(xù)的其他請求卡住的問題，從而提高了基于cifs協(xié)議下創(chuàng)建小文件的效率。

本發(fā)明實施例公開了一種具體的基于cifs協(xié)議創(chuàng)建小文件的方法，相對于上一實施例，本實施例對技術(shù)方案作了進一步的說明和優(yōu)化。參見圖2所示，具體的：

步驟s21：利用主線程發(fā)送的open處理判斷結(jié)果，間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程，其中，open處理判斷結(jié)果為主線程判斷是否在預(yù)設(shè)時間內(nèi)接收到子線程發(fā)送的open處理結(jié)果的判斷結(jié)果。

具體的，為保證創(chuàng)建小文件的效率，因此，主線程預(yù)先設(shè)定預(yù)設(shè)時間，根據(jù)子線程是否在預(yù)設(shè)時間內(nèi)發(fā)送open處理結(jié)果，生成open處理判斷結(jié)果，主線程將open處理判斷結(jié)果發(fā)送至客戶端，客戶端則在接收到open處理判斷結(jié)果后中斷與open處理判斷結(jié)果相應(yīng)的創(chuàng)建文件請求，從而釋放客戶端與主線程之間的線程，客戶端再發(fā)送下一個創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程，以使主線程對請求進行相應(yīng)的操作，從而形成客戶端利用open處理判斷結(jié)果間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程。

其中，當(dāng)主線程在預(yù)設(shè)時間內(nèi)未接收到子線程發(fā)送的open處理結(jié)果，則判定子線程處理open事件超時，生成open處理判斷超時結(jié)果，發(fā)送至客戶端，客戶端接收到open處理判斷超時結(jié)果，則切斷與open處理判斷超時結(jié)果相應(yīng)的創(chuàng)建文件請求與主線程的線程，并繼續(xù)的間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程。

其中，當(dāng)主線程在預(yù)設(shè)時間內(nèi)接收到子線程發(fā)送的open處理結(jié)果，則判定子線程處理open事件成功，在主線程接收到子線程發(fā)送的open處理結(jié)果后，生成open處理判斷成功結(jié)果，發(fā)送至客戶端，客戶端接收到open處理判斷成功結(jié)果，則切斷與open處理判斷成功結(jié)果相應(yīng)的創(chuàng)建文件請求與主線程的線程，并繼續(xù)的間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程。

例如，預(yù)設(shè)時間為10ms，如主線程在10ms內(nèi)未接收到子線程發(fā)送的open處理結(jié)果，則生成open處理判斷超時結(jié)果，如主線程在10ms內(nèi)接收到子線程發(fā)送的open處理結(jié)果，則在主線程接收到子線程發(fā)送的open處理結(jié)果后，生成open處理判斷成功結(jié)果。

可以理解的是，open處理判斷結(jié)果最晚在預(yù)設(shè)時間到達后發(fā)送至客戶端，最快則是在主線程接收到子線程發(fā)送的open處理結(jié)果后發(fā)送至客戶端，即，open處理判斷超時結(jié)果的發(fā)送時間由預(yù)設(shè)時間決定，open處理判斷成功結(jié)果的發(fā)送時間由主線程接收到子線程發(fā)送的open處理結(jié)果的時間決定。

進一步的，當(dāng)客戶端接收到open處理判斷超時結(jié)果，客戶端仍需向主線程發(fā)送未完成的創(chuàng)建文件請求，其具體過程可以包括步驟s211；其中，

步驟s211：利用主線程發(fā)送的open處理判斷超時結(jié)果，生成創(chuàng)建文件請求失敗記錄，利用創(chuàng)建文件請求失敗記錄，間斷的逐個發(fā)送創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程。

具體的，客戶端可以利用創(chuàng)建文件請求失敗記錄，在創(chuàng)建文件請求集中的創(chuàng)建請求均發(fā)送過主線程后，間斷的逐個發(fā)送創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程；還可以，在客戶端每發(fā)送預(yù)設(shè)閾值未發(fā)送過主線程的創(chuàng)建文件請求后，發(fā)送一個創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程。

例如，創(chuàng)建文件請求集中包括10個創(chuàng)建文件請求，其中，有3個創(chuàng)建文件請求失敗，記錄在創(chuàng)建文件請求失敗記錄，分別是第三創(chuàng)建文件請求、第四創(chuàng)建文件請求和第8創(chuàng)建文件請求，客戶端可以利用創(chuàng)建文件請求失敗記錄，在創(chuàng)建文件請求集中的10個創(chuàng)建文件請求均發(fā)送過主線程后，間斷的逐個發(fā)送創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求；還可以預(yù)設(shè)閾值為3，客戶端每發(fā)送3個未發(fā)送過主線程的創(chuàng)建文件請求后，發(fā)送一個創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程，如，當(dāng)客戶端發(fā)送到第三創(chuàng)建文件請求時，客戶端可以發(fā)送一個創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求，在第三創(chuàng)建文件請求處理后，第三創(chuàng)建文件請求變?yōu)閯?chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求，則客戶端第四次再次發(fā)送第三創(chuàng)建文件請求至主線程，客戶端第五次發(fā)送第四創(chuàng)建文件請求，此時計算閾值，記為1，直到客戶端發(fā)送3個未發(fā)送過主線程的創(chuàng)建文件請求后，發(fā)送一個創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程，客戶端在發(fā)送第六創(chuàng)建文件請求后，發(fā)送第四創(chuàng)建文件請求至主線程，客戶端在發(fā)送第九創(chuàng)建文件請求后，發(fā)送第八創(chuàng)建文件請求至主線程。

步驟s22：利用主線程判斷與創(chuàng)建文件請求相應(yīng)的open事件是否發(fā)送到子線程集中的空閑子線程。

具體的，因為客戶端在接收到open處理判斷超時結(jié)果后，會重復(fù)發(fā)送創(chuàng)建文件請求失敗過的創(chuàng)建文件請求，因此，主線程判斷與創(chuàng)建文件請求相應(yīng)的open事件是否發(fā)送到子線程集中的空閑子線程，以避免重復(fù)發(fā)送open事件至子線程，占用線程資源。

步驟s23：如果已發(fā)送，則不再利用主線程向子線程集中的空閑子線程發(fā)送open事件。

步驟s24：如果未發(fā)送，則利用主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，以使子線程集中接收open事件的子線程完成對open事件的處理，其中，空閑子線程為沒有正在處理open事件的子線程。

相應(yīng)的，本發(fā)明實施例還公開了一種基于cifs協(xié)議創(chuàng)建小文件的系統(tǒng)，參見圖3所示，該系統(tǒng)包括：

創(chuàng)建請求發(fā)送模塊11，用于間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程；

open事件發(fā)送模塊12，用于利用主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，以使子線程集中接收open事件的子線程完成對open事件的處理，其中，空閑子線程為沒有正在處理open事件的子線程。

可見，本發(fā)明實施例客戶端在間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程后，主線程將與創(chuàng)建文件請求相應(yīng)的open事件發(fā)送到子線程集中的空閑子線程，而主線程本身不再進行open事件的處理，由子線程集中的多個空閑子線程分別處理不同創(chuàng)建文件請求相應(yīng)的open事件，因此即使一個open事件在一個子線程中處理緩慢，也不會影響主線程繼續(xù)接收客戶端發(fā)送創(chuàng)建文件請求和其余子線程并行異步處理其他open事件的進度，解決創(chuàng)建文件時因為open調(diào)用時延較長導(dǎo)致后續(xù)的其他請求卡住的問題，從而提高了基于cifs協(xié)議下創(chuàng)建小文件的效率。

本發(fā)明實施例中，上述創(chuàng)建請求發(fā)送模塊11，可以具體用于利用主線程發(fā)送的open處理判斷結(jié)果，間斷的逐個發(fā)送創(chuàng)建文件請求集中的創(chuàng)建文件請求至主線程，其中，open處理判斷結(jié)果為主線程判斷是否在預(yù)設(shè)時間內(nèi)接收到子線程發(fā)送的open處理結(jié)果的判斷結(jié)果。

進一步的，上述創(chuàng)建請求發(fā)送模塊11，可以包括失敗請求發(fā)送單元；其中，

失敗請求發(fā)送單元，用于利用主線程發(fā)送的open處理判斷超時結(jié)果，生成創(chuàng)建文件請求失敗記錄，利用創(chuàng)建文件請求失敗記錄，間斷的逐個發(fā)送創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程。

進一步的，上述失敗請求發(fā)送單元，可以具體用于利用創(chuàng)建文件請求失敗記錄，在創(chuàng)建文件請求集中的創(chuàng)建請求均發(fā)送過主線程后，間斷的逐個發(fā)送創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程；

或，利用創(chuàng)建文件請求失敗記錄，在每發(fā)送預(yù)設(shè)閾值未發(fā)送過主線程的創(chuàng)建文件請求后，發(fā)送一個創(chuàng)建文件請求失敗記錄中的創(chuàng)建文件請求至主線程。

本發(fā)明實施例中，基于cifs協(xié)議創(chuàng)建小文件的系統(tǒng)，還可以包括重復(fù)發(fā)送判斷模塊和事件發(fā)送終止模塊；其中，

重復(fù)發(fā)送判斷模塊，用于利用主線程判斷與創(chuàng)建文件請求相應(yīng)的open事件是否發(fā)送到子線程集中的空閑子線程；

事件發(fā)送終止模塊，用于重復(fù)發(fā)送判斷模塊判定與創(chuàng)建文件請求相應(yīng)的open事件已發(fā)送到子線程集中的空閑子線程，則不再利用主線程向子線程集中的空閑子線程發(fā)送open事件。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

以上對本發(fā)明所提供的一種基于cifs協(xié)議創(chuàng)建小文件的方法及系統(tǒng)進行了詳細介紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實施方式及應(yīng)用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。