什麼是比較客戶端和遠程服務器

Question

文件列表中的有效方法，我有以下情況，需要加以解決的效率，

我做的文件同步，從客戶端設備到服務器。由於服務器存在一些問題，有時會發生某些設備中的文件無法從服務器獲取到其他設備。我需要確保服務器中的所有文件都使用單獨的線程同步到所有客戶端設備。我正在使用C++進行客戶端到服務器通信的開發和libcurl。

在客戶端設備中，我們在SQLite數據庫中有一個用於下載文件的條目。同樣在服務器中，我們也在服務器數據庫（MySQL）中也有類似的更新。我需要列出來自客戶端設備的所有可用文件並將其發送給服務器，並且必須將其與來自服務器數據庫的列表進行比較以找出錯過的文件。

我做了一個粗略的估計，對於100萬個文件列表（文件名全路徑），大小約爲85 MB。壓縮後，它可以達到10 MB的大小。因此，將整個文件列表（即使在壓縮之後）從客戶端傳輸到服務器並不是一個好主意。我打算爲此實現Bloom Filter，如下所示，

1. 從客戶端數據庫獲取文件列表並將它們轉換爲Bloom Filter Data Structure。
2. 僅將bloom數據結構從客戶端傳輸到服務器。
3. 從服務器端數據庫獲取文件列表，並將其與來自客戶端的Bloom數據結構進行比較，找出丟失的文件。

請注意，從客戶端發起的上述過程應該在線程中定期處理，每隔1小時左右處理一次。

布盧姆過濾器的問題是假陽性率，即使它非常低。我不想錯過任何一個文件。還有其他更好的方法嗎？

Answer 1

正如您已經注意到的，這不是Bloom Filters適用的問題。使用布隆過濾器時，您必須檢查權威來源以區分假陽性和真陽性 - 在針對過濾器的大多數查詢預計會產生負數結果的情況下，它們非常有用，這與你的情況相反。

你可以做的是讓每一邊都建立一個部分前綴樹來記憶所有已知的文件名。它不會是一個完整的前綴樹 - 一旦一個節點下的文件名數量下降到某個水平以下，您只需在該節點中包含這些文件名的完整列表。然後使用從樹根開始的遞歸算法同步這些前綴樹：

1. 每一端都會創建一個哈希，它包含當前節點下面的所有已排序的連接文件名。
2. 如果哈希值相等，那麼這個節點和所有的後代是同步的 - 返回。
3. 如果沒有子節點，則將此終端節點上的（短）文件名列表從一側發送到另一側進行同步並返回。
4. 否則，遞歸同步子節點並返回。

散列值應該至少爲128位，並確保當您以可逆方式連接散列的文件名時（即將它們與不能出現在文件名中的字符分隔開\0，或用每個長度前綴）。

Answer 2

在文件/路徑名壓縮中我發現前綴後綴壓縮甚至比通用（bz2）壓縮更獨立地工作。結合時，文件名列表可以減少更多。

訣竅是使用轉義代碼（例如< 32）來指示前一行的常用字符數，然後使用常規字符作爲唯一部分，最後（可選）在最後（可選）編碼常用字符數的字符串。