檔案雙向同步的一點想法

2022-08-13 11:33:10 字數 1378 閱讀 8417

研究了兩天也沒找到個很好的辦法, 這裡記錄一下研究過的辦法以及提出乙個設想

1, inotify-tools + rsync

使用inotify-watch監視資料夾, 有改動即執行rsync

安裝使用簡單, 滿足實時的需要, 但不能雙向,效能也是瓶頸

2, sersync

inotify + rsync, c++ 編寫, 配置較多,能滿足一些複雜的需求, 如過濾和plugin, 能滿足實時的需求,效能也不錯(經測試, 一次同步8000個檔案沒有問題, 而且不管原有多少檔案,同步檔案的時間比較固定),而且有出錯重傳機制, 唯一的遺憾是只能單向同步, 因為,它也是監控主伺服器上的資料夾有改動即對修改的檔案執行rsync。

3, openduckbill

和sersync差不多,使用pyinotify + rsync

4, csync + inotify

安裝配置麻煩, 而且用了inotify的基本都只是單向

5,lsyncd

和sersync一樣的

6,unison

可雙向同步的工具, 但要做到實時好像不容易, 如果加上inotify-tools的話估計效能會有問題, 也不宜實現

看過這麼多都不行,看來用現有工具是不行了,換個思路

1, 單純用nfs, 建立乙個共享的檔案目錄

取決於網路,而且會有單點瓶頸

2, gfs

好像是redhat專用? 沒太調查

3, hadoop等分布式檔案系統

以現有使用hadoop的經驗看來,讀取檔案的速度上達不到要求,而且hadoop也不適宜大量小檔案的讀寫。 如果在每台機器上保持乙個一直與存在於hadoop上的資料夾同步的資料夾,即每天機器對hadoop檔案有個cache,這樣可以部分解決同步問題,當然實時性不會是秒級了,應該是分鐘級了。不過這是個思路。

我覺的更好的乙個想法是用nfs+inotify+ vc(verison control) 

比如有兩台伺服器,一台主一台從, 從伺服器也會接受少量資料請求, 在從伺服器上mount乙個主伺服器的目錄, 對於從伺服器來說,同步就變成本地兩個目錄的同步了, 分別對應本地目錄和nfs目錄構建乙個樹形結構的檔案版本樹, 用inotify監控這兩個目錄, 當發現有檔案被修改時,將它的檔案版本樹上該檔案版本加1, 並且將改動在版本樹向上擴充套件到根目錄, 乙個執行緒不段比較兩個版本樹的根目錄,如果版本不一樣,則依次查詢比較下面子目錄的版本號,這樣遞迴找到被修改的檔案,然後將高版本的檔案copy覆蓋低版本的檔案。

我覺得這個想法是可行的, 利用inotify實時同步檔案, verison control雙向改動檔案, 使用nfs是不想接觸tcp那一層, 簡化實現的複雜度, 而且整個系統跑在從伺服器上,不會影響主伺服器的應用, 但這也只是我乙個簡單的想法,還有很多細節需要完善的地方, 而且比較上面會有一定的工作量。

檔案雙向同步的一點想法

研究了兩天也沒找到個很好的辦法,這裡記錄一下研究過的辦法以及提出乙個設想 1,inotify tools rsync 使用inotify watch監視資料夾,有改動即執行rsync 安裝使用簡單,滿足實時的需要,但不能雙向,效能也是瓶頸 2,sersync inotify rsync,c 編寫,配...

最近一點想法

本來計畫每天11點半之前睡覺,事實證明不太可能每天那麼規律。一是,每週任務不會順利按計畫進行。二是,我本人有時候凌晨睡,五點半起ok,有時候夜幕降臨就要困得昏過去。這樣的話,就爭取精神狀態好的時候多做點事,狀態不好就多休息,不去刻意按時睡了。只是有一點,臉上從不長痘的我,也開始長痘了。不知道是春天有...

一點小想法

關於一點應用加速的心得 1.為了不影響使用者體驗,可以單獨開執行緒來完成費時的操作 thread thread new thread new runable public void run 寫在這裡 2.其實對於一些應用來說,可以把運算的結果儲存起來,下次直接讀取資料,這樣可以節約不少時間。3.盡量...