基于fastNTsync算法的海量小文件同步優化方法研究＊

華 南，朱彥霞

(1.河南中廣智媒科技有限公司，河南 鄭州 450000；2.中國廣電河南網絡有限公司；3.河南省職工醫院；4.河南省鄭州工人療養院)

0 引言

隨著云計算、物聯網和大數據技術的發展，海量數據的傳輸和存儲成為了一個亟待解決的問題。對于小文件的傳輸，由于其“個體小、總量多”[1]的特點，給數據傳輸帶來了很大的困難，同時也帶來了存儲空間浪費、經濟損失[2]等問題。

目前，已經有多種小文件傳輸優化方案（如基于云計算[3-4]、并行計算[5-6]、多線程和UDP 協議[7-8]等)，但是仍然存在依賴云計算服務，依賴硬件和網絡設備以及數據丟失或重復傳輸等問題；Windows 操作系統中基于NTFS 分區格式的小文件傳輸方案表現良好，但仍面臨使用負擔較大、效率低、跨網絡海量小文件同步等問題；基于Windows 操作系統的小文件傳輸方案Robocopy、Fastcopy、TeraCopy、Synctoy 等，支持多線程傳輸、斷點續傳等功能，然而相比Linux 平臺，存在學習使用負擔較大的問題、跨網絡海量小文件同步、傳輸效率低、高性能產品收費成本高等問題；Windows操作系統中活動目錄技術支持DFS 文件服務并提供強大的數據同步功能，但其依賴許多服務和配置才能使用，在技術上缺乏靈活性。此外，通過RPC 映射目錄的同步方法可以通過優化拷貝方式進行同步[9]，但由于底層協議的原因，當傳輸海量文件時，整體性能會下降，特別是當傳輸中斷時，進行數據對比將耗費更多時間。

因此，海量小文件同步傳輸及性能優化問題是個技術難點，也是當今云計算技術研究的一個熱點。為了解決這個問題，需要設計出更高效、可靠、安全的同步傳輸方案，并通過優化算法和技術手段來提高同步效率和速度，降低成本，從而更好地滿足人們日益增長的數據傳輸需求。

1 算法設計

在標準的Windows 操作系統中，進行兩個終端之間的文件傳輸（例如，從PC1 到PC2 傳輸1000 個文件）如圖1所示。標準的Windows操作系統會對每個文件執行一次完整的磁盤和網絡傳輸流程，無論文件大小如何，這導致在傳輸大量文件時速度非常慢。此外，網絡傳輸時協議的握手次數并沒有減少，也會導致傳輸速度下降。

在不考慮LOFS（Loss of Service Faults）的情況下，傳輸速率（R）與擁塞窗口和數據包往返時間之間存在一定的關系。具體來說，傳輸速率與擁塞窗口和數據包往返時間的乘積成正比，即：

R=y/RTT

其中，y 表示當前擁塞窗口的大小，即網絡中可以發送的數據包數量，RTT 表示數據包往返時間，即從發送端發送一個數據包到接收端并收到確認的時間。上述關系式表明，當擁塞窗口y 增加或數據包往返時間RTT減小時，傳輸速率R也會相應增加，反之亦然。這是因為當擁塞窗口y 增加時，網絡中可以發送的數據包數量也會增加，傳輸效率提高；而當數據包往返時間RTT 減小時，數據包能夠更快地在發送端和接收端之間傳輸，從而也提高了傳輸效率。

在考慮LOSF 傳輸情況下，在慢啟動階段，擁塞窗口大小的計算公式為：

y=min(W,CWND)

其中，y 表示當前擁塞窗口的大小，W 表示擁塞窗口的上限，CWND 表示當前的擁塞窗口大小。在慢啟動階段，CWND 的初始值為1，每經過一個往返時間RTT，CWND 的值就會加倍，即CWND=CWND*2。因此，可以將擁塞窗口y的計算公式表示為：

y=min(W,2^n)

其中，n 表示當前慢啟動階段經過的往返時間RTT 的個數，W表示擁塞窗口的上限。

在考慮LOSF傳輸情況下，傳輸速率為：

R=(MFS/RTT)*sqrt(2/p)

其中，R 表示傳輸速率，MFS 表示文件集的平均大小，RTT 表示往返時間，p 表示丟包率。這個表達式中，sqrt(2/p)表示LOFS 因子，描述了網絡中丟包率對傳輸速率的影響。在不考慮丟包的情況下，傳輸速率與文件大小呈現正相關性，即隨著文件大小增加，傳輸速率會相應增加；如果傳輸文件數量過多，會產生多個RTT 浪費，文件過小，網絡帶寬不能充分利用，對吞吐量產生影響、效率低下。

雖然有一些第三方免費和收費軟件可在一定程度上提升大量小文件傳輸效率，例如從Linux 上移植的Rsync，但由于這些軟件是基于Linux 開發的，對于中文和Windows 平臺特殊的NTFS 存儲技術兼容性較差。當同步的文件過大或文件數量過多時，也會出現兼容性問題。

對此，可以利用Windows 7 及其后續操作系統的特性，結合最新的設計思路來實現文件的高速同步。本文提出并構建了一種高效的Windows 文件同步算法fastNTsync，該算法基于以下三種技術優勢：

⑴NTFS分區表快照技術

該技術能夠在不中斷文件系統的情況下對NTFS分區表完成快照，從而提高同步的效率?？煺湛捎糜谟涗浄謪^表的狀態，以便在同步期間快速檢測和比較分區表的變化。

⑵NTFS $MFT分析技術

該技術可分析NTFS文件系統的主文件表（$MFT），以便快速獲取文件信息。這有助于減少網絡傳輸量和提高同步效率。

⑶文件打包分區組合拷貝技術

該技術可將文件按照一定的規則打包成一個包，并在傳輸過程中對包進行組合拷貝。這有助于減少網絡傳輸次數和提高同步效率。

本文提出的fastNTsync 算法融合了以上三種技術，可顯著提高文件同步的效率和速度，同時解決了NTFS特殊性和中文兼容性問題。

2 fastNTsync算法實現及性能驗證

2.1 開發運行環境

fastNTsync 算法以Microsoft 的.NET Core 5 為主要開發平臺，使用C#語言開發，并使用LiteDB 數據庫作為嵌入式數據庫。模擬物理環境使用Oracle VM VirtualBox 開源虛擬機來仿真多機環境，網絡采用NAT方式。虛擬機分別模擬一部分Linux/Windows環境，實驗環境網絡實際為10000M 以太網卡傳輸（網絡配置如圖2所示）。

圖2 網絡配置信息圖

2.2 fastNTsync算法實現思路及偽代碼

fastNTsync 算法采用公共的RSA 庫和改進過的128 位hash 算法來提高數據傳輸的安全性和效率，同時應用第三方開源ZIP 庫實現文件塊的打包提高文件傳輸效率,在實際應用過程中還應考慮文件沖突、同步隊列管理和異常處理等細節問題。

2.2.1 fastNTsync算法具體實現思路

具體實現思路如下：

⑴同步服務器端啟動后，使用開源庫獲取發起端的NTFS索引和文件映射表$MFT數據，并將其拷貝到內存流中形成快照，以支持文件同步。

⑵解析NTFS 索引和$MFT 數據，獲取需要同步的目錄和文件樹結構，包括文件名、字節長度、修改時間等信息，并將這些數據寫入LiteDB 數據庫，以支持快速的同步任務處理。

⑶開啟HTTP 服務，允許同步客戶端通過驗證碼和同步任務ID 來獲取LiteDB 的快照庫，以支持遠程同步操作。

⑷允許同步客戶端掃描設定的同步存儲目錄和文件結構，包括文件名、目錄結構、文件CRC、字節長度、修改時間和校驗128 位hash，并將這些索引數據存儲到本地LiteDB數據庫中，以便進行同步數據對比。

⑸通過比較客戶端和服務端LiteDB 數據庫中的索引數據，對需要同步的新增、修改和刪除操作進行識別，并將這些操作轉化為HTTP 請求，以支持遠程同步操作。

⑹同步客戶端通過HTTP 請求獲取需要同步的文件內容，然后通過文件流的方式，將文件寫入本地存儲，以實現同步文件的傳輸。

⑺同步過程中可以使用正則表達式來排除不需要同步的文件類型，同時可以配置同步速度限制，以避免網絡帶寬資源被占滿。

2.2.2 編碼實現

fastNTsync算法偽代碼如下：

2.2.3 算法核心過程

⑴利用NTFS分區表的特性和Hash碼提升文件同步效率

Windows NTFS分區表身攜帶文件的長度和修改時間信息，通過計算Hash 碼進行快速比對，避免了對文件內容的重復讀取和計算Hash 碼的過程，提高了文件同步的效率。

⑵小文件打包優化網絡傳輸效率

在文件同步過程中，使用無壓縮打包的方式優化網絡傳輸效率。因為Windows 在網絡之間傳輸小于512KB 甚至更低容量的小文件的效率并不高，使用無壓縮打包的方法可以提高網絡傳輸效率，從而提高同步效率。

⑶多線程傳輸提升文件同步效率

采用多線程傳輸技術提升網絡并發效率。至少使用兩個線程，同時處理多個文件的傳輸，從而減少傳輸時間，提高文件同步效率。

⑷利用NTFS索引及文件映射表特點提升文件同步效率

通過獲取發起端NTFS的索引和文件映射表$MFT數據，以獲取文件列表，減少I/O 請求，避免對文件系統的重復讀取和計算，效率遠遠超過傳統的文件遞歸檢索效率。這樣可加快文件同步速度，提高同步效率。

2.3 fastNTsync算法性能驗證

算法性能驗證過程如圖3所示。

圖3 算法驗證過程

具體驗證過程描述如下：

⑴ 通過fastNTsync 程序的函數-init_test 1，在PC1 的F 盤的目錄f:svn estA 中創建6,546 個隨機大小的.txt 的測試文件，硬盤使用傳統的機械硬盤，總共約14GB 左右，最小的文件約1KB，最大的約300MB；其中，小于512KB 的文件有873 個。同時，在PC2 的E 盤中建立testA的空目錄。

⑵在兩臺PC上配置fastNTsync.exe的配置信息，配置如下：

別名PC1IP:192.168.31.25

端口為7000，設定同步目錄為：f: estB

別名PC2 IP:192.168.31.24

端口為7000，設定同步目錄為：e: estB

⑶通過標準的Windows 命令，從PC1 電腦發起f:svn estA 到192.168.31.24e$（192.168.31.24 是PC2 的IP）進行文件拷貝，大文件與小文件在傳輸速率上差異性較為明顯（如圖4、圖5 所示），系統估算平均用時為5分13秒。

圖4 Windows自帶Copy命令實現大文件傳輸速率示例圖

圖5 Windows自帶Copy命令實現大量小文件傳輸速率示例圖

由于小文件較多，網絡傳輸實際速度大致在20Mbps～993Mbps左右徘徊。

⑷復制PC1 的testA 目錄一份為testB，執行命令fastNTsync.exe -s PC1 -t PC2，開始同步；大文件與小文件傳輸速率基本無差異（如圖6 所示），系統估算用時約1分17秒。

圖6 fastNTsync.exe在覆蓋模式下的速率

圖7 Windows文件資源管理器傳輸在覆蓋模式下的速率

通過對比可以看出，在相同環境及傳輸任務下，本文所提出的fastNTsync算法較傳統Windows命令的執行效率優勢更為突出。

第二次測試過程：PC1 的testA 文件并再次執行fastNTsync 程序的函數-init_test2，生成測試數據文件增加為7329 個，并且隨機重寫了PC1 的testA 目錄下一些文件內容，最終test 目錄大小為16.4 GB 左右。目前PC1和PC2大約有1000個以上的差異文件。

⑸進行第二次同步時，分別使用標準的Windows命令復制PC1 到PC2 的文件（直接覆蓋）和改進后的fastNTsync.exe 程序進行同步。實驗結果顯示，使用Windows 命令復制文件的同步過程耗時6 分40 秒，而使用fastNTsync程序的同步過程僅耗時約58秒。

經過綜合評測，fastNTsync算法采用NTFS快照技術高效地檢索和比對兩臺待同步計算機的文件列表信息，從而僅同步需要更新的文件。此外，該算法對于小文件進行了打包和解包處理，減少了網絡協議握手次數，提高了文件傳輸效率。

3 總結

隨著數據量不斷增加，海量小文件同步問題已成為一個重要問題。本文提出了一種基于fastNTsync算法的海量小文件同步優化算法，該算法充分融合了NTFS 分區表快照、NTFS $MFT 分析和文件打包分區組合拷貝等技術優勢。通過優化同步過程中的數據傳輸、數據存儲和數據管理等方面，該算法有效地提高了同步速度和效率，并實現了較高的同步質量。

實驗結果表明，本文提出的fastNTsync 算法在處理大量小文件時具有顯著的優勢。相比現有同步算法，該算法可以更快地完成同步任務，同時也能夠更加高效地利用存儲空間。該算法的性能優勢為海量小文件同步問題的解決提供了一種有效的解決方案，同時也為相關領域的研究和應用提供了有價值的參考。

雖然本文的fastNTsync算法能夠有效解決海量小文件同步問題，但在實際應用中，仍需考慮不同環境下的應用效果、系統的穩定性和安全性等問題。未來的研究可以探究更加先進的同步算法，同時結合機器學習和人工智能等技術，進一步提高同步效率和準確性。