大量小文件的實時同步的解決方案分析
2024-07-16 17:44:54
供稿：網友
傳統的文件同步方案有rsync(單向) 和 unison(雙向)等，它們需要掃描所有文件后進行比對，差量傳輸。如果文件數量達到了百萬甚至千萬量級，掃描所有文件將非常耗時。而且正在發生變化的往往是其中很少的一部分，這是非常低效的方式。
之前看了Amazon的Dynamo的設計文檔，它們每個節點的數據是通過Hash Tree來實現同步，既有通過日志來同步的軟實時特點(msyql, bdb等)，也可以保證最終數據的一致性(rsync, unison等)。Hash Tree的大體思路是將所有數據存儲成樹狀結構，每個節點的Hash是其所有子節點的Hash的Hash，葉子節點的Hash是其內容的Hash。這樣一旦某個節點發生變化，其Hash的變化會迅速傳播到根節點。需要同步的系統只需要不斷查詢跟節點的hash，一旦有變化，順著樹狀結構就能夠在logN級別的時間找到發生變化的內容，馬上同步。
文件系統天然的是樹狀結構，盡管不是平衡的數。如果文件的修改時間是可靠的，可以表征文件的變化，那就可以用它作為文件的Hash值。另一方面，文件的修改通常是按順序執行的，后修改的文件比早修改的文件具有更大的修改時間，這樣就可以把一個目錄內的最大修改時間作為它的修改時間，以實現Hash Tree。這樣，一旦某個文件被修改，修改時間的信息就會迅速傳播到根目錄。
一般的文件系統都不是這樣做的，目錄的修改時間表示的是目錄結構最后發生變化的時間，不包括子目錄，否則會不堪重負。因為我們需要自己實現這個功能，利用Linux 2.6內核的新特性inotify獲得某個目錄內文件發生變化的信息，并把其修改時間傳播到它的上級目錄(以及再上級目錄)。Python 有 pyinotify，watch.py的代碼如下：
復制代碼代碼如下:
#!/usr/bin/python
from pyinotify import *
import os, os.path
flags = IN_CLOSE_WRITE|IN_CREATE|IN_Q_OVERFLOW
dirs = {}
base = '/log/lighttpd/cache/images/icon/u241'
base = 'tmp'
class UpdateParentDir(ProcessEvent):
def process_IN_CLOSE_WRITE(self, event):
print 'modify', event.pathname
mtime = os.path.getmtime(event.pathname)
p = event.path
while p.startswith(base):
m = os.path.getmtime(p)
if m < mtime:
print 'update', p
os.utime(p, (mtime,mtime))
elif m > mtime:
mtime = m
p = os.path.dirname(p)
process_IN_MODIFY = process_IN_CLOSE_WRITE
def process_IN_Q_OVERFLOW(self, event):
print 'over flow'
max_queued_events.value *= 2
def process_default(self, event):
pass
wm = WatchManager()
notifier = Notifier(wm, UpdateParentDir())
dirs.update(wm.add_watch(base, flags, rec=True, auto_add=True))
notifier.loop()
在已經有Hash Tree的時候，同步就比較簡單了，不停地獲取根目錄的修改時間并順著目錄結構往下找即可。需要注意的是，在更新完文件后，需要設置修改時間為原文件的修改時間，目錄也是，保證Hash Tree的一致性，否則沒法同步。mirror.py的代碼如下
