sersync 專案利用 inotify 和 rsync 技術實現對伺服器資料實時同步的解決方案，其中 inotify 用於監控 sersync 所在伺服器上檔案系統的事件變化，而 rsync 是目前廣泛使用的本地以及異地資料同步工具，其優點是只對變化的目錄資料操作，甚至是乙個檔案不同的部分進行同步，所以其優勢大大超過使用掛接檔案系統或 scp 等方式進行映象同步。
目前使用比較多的同步工具為 inotify-tools 和 openduckbill。inotify-tools 在前面的博文介紹過，這裡就不做闡述。簡單說下 openduckbill，openduckbill 也是
google 的乙個開源專案，它也是依賴於inotif-tools，並且它 和 inotify都是基於指令碼語言編寫的，其設計思路同樣是採用檔案系統事件監控機制 inotify 與 rsync 命令 來做設計架構的。這裡在多說一點，有些朋友可能會在兩台甚至多台伺服器之間，互相搭建 inotify-tools + rsync 之類的同步部署來做互相同步，這個是很不推薦的，主要一方面就是在同步的檔案時間戳上容易出問題，導致同步失敗，甚至版本不同步。因此，如果你是要做互相同步，推薦使用 csync 。
這裡呢，就說說
sersync 優於 inotify-tools 和 openduckbill 的地方吧！
1、sersync 使用 c++ 編寫，對 linux 系統檔案產生的臨時檔案和重複的檔案操作會進行過濾，在本文後面會提到該點。使用sersyc和rsync結合做同步的時候，會大大減少執行時所消耗的本地以及網路資源，因此在速度方面有顯著提公升。
3、sersync 採用多執行緒（預設10）進行同步（即可以併發同步多個不同檔案），尤其是針對較大檔案同步的時候，它能夠保證多個伺服器實時保持同步狀態。
4、sersync 自帶了出錯處理機制。它可以通過失敗佇列自動對之前出錯的檔案進行重新同步操作。如果屆時依舊失敗，它會每 10 個小時對同步失敗的檔案再進行重新同步操作，直到檔案同步為止。
5、sersync 自帶有 crontab 功能，因此不需要借助系統的 crontab ，只需在 xml 配置檔案中開啟該功能，即可按預先的配置，每隔一段時間自動做一次整體同步操作。
6、sersync 還自帶了socket 與 refreshcdn
的協議擴充套件，可以滿足有特殊需求的公司二次開發。（之前的版本有http擴充套件，目前已去除）
下面是，sersync 的設計結構圖：
以上是 sersync 谷歌專案組上面的設計結構圖！現在可能是因為某些原因（你懂得），不能訪問谷歌的頁面，即使用某種方式出去也不能這個也是打不開狀態了。本人之前珍藏的有，因此這裡特把該圖貼出，方便大家學習。
鑑於，英文版本可能對廣大博友帶來閱讀壓力，下面特貼出中文翻譯過的版本。
針對上圖的設計架構，這裡做幾點說明，來幫助大家閱讀和理解該圖：
1、執行緒組執行緒是等待執行緒佇列的守護執行緒，當事件佇列中有事件產生的時候，執行緒組守護執行緒就會逐個喚醒同步執行緒。當佇列中 inotify 事件較多的時候，同步執行緒就會被全部喚醒一起工作。這樣設計的目的是為了能夠同時處理多個 inotify 事件，從而提公升伺服器的併發同步能力。同步執行緒的最佳數量=核數 x 2 + 2。
那麼之所以稱之為執行緒組執行緒，是因為每個執行緒在工作的時候，會根據伺服器上新寫入檔案的數量去建立子執行緒，子執行緒可以保證所有的檔案與各個伺服器同時同步。當要同步的檔案較大的時候，這樣的設計可以保證每個遠端伺服器都可以同時獲得需要同步的檔案。
2、服務執行緒的作用有三個：
a、處理同步失敗的檔案，將這些檔案再次同步，對於再次同步失敗的檔案會生成 rsync_fail_log.sh 指令碼，記錄失敗的事件。
b、每隔10個小時執行 rsync_fail_log.sh 指令碼一次，同時清空指令碼。
c、crontab功能，可以每隔一定時間，將所有路徑整體同步一次。
3、過濾佇列的建立是為了過濾短時間內產生的重複的inotify資訊，例如在刪除資料夾的時候，inotify就會同時產生刪除資料夾裡的檔案與刪除資料夾的事件，通過過濾佇列，當刪除資料夾事件產生的時候，會將之前加入佇列的刪除檔案的事件全部過濾掉，這樣只產生一條刪除資料夾的事件，從而減輕了同步的負擔。同時對於修改檔案的操作的時候，會產生臨時檔案的重複操作。
ifnotify事件分析
下面來用具體資料去做分析，來解釋為什麼 sersync 比 inotify-tools 和 openduckbill 更優秀！
首先來看一張圖，這張圖是從谷歌 sersync 專案組的分析文件裡面摘出來的，該圖是對同乙個檔案做write and close操作的時候，產生的10個事件。
為什麼我們認為指令碼監控效率低?
由於我們執行複製，移動，新建，刪除等操作時，會產生諸多事件。又上圖來看他除了產生.開頭的隱藏臨時檔案和~結尾的臨時檔案，還產生了3個4913的數字命名的臨時檔案（注意，在 write 檔案的時候，總會產生這3個數字檔案，除非write的檔名叫做4913時，才會產生別的數字命名的事件）。
因此當我們使用指令碼監控，即使通過使用 --exclude 這樣的選項結合正則語法，也無法完美過濾掉一些檔案系統產生的臨時檔案和臨時事件，這樣就造成了 rsync 的反覆執行。即便你把「.」開頭與「~」結尾的事件過濾了，對於test檔案仍舊有3次操作，分別是8、64和256。
補充：
這裡簡單介紹下事件名稱與對應**。事件256代表create事件，事件8代表write_close事件，事件512代表remove事件，事件64是move_from事件，即將檔案mv出當前路徑時產生事件。事件128是move_to事件，即將其它路徑的檔案移入到當前路徑。移出與移入操作可以通過cookie值來確定是否是同一檔案。由此可見，當移動操作時候，是將 test 移動為 test~ ，其實是修改了名字，通過 cookie 可以看出，它們是對同一檔案的操作。
此時，我們 sersync 的過濾佇列效果就出來了！
以下是過濾佇列的三大作用！
1、過濾佇列的第乙個作用
按照如上的情形，如果通過過濾佇列，就只會剩下乙個 8 號事件，一定程度上也提高了同步的效率。
2、過濾佇列的第二個作用
當你在本機刪除目錄的時候，假設你刪除了乙個包含 5 個檔案的目錄。inotify 會產生 6 個事件出來，分別是 5 個檔案刪除事件和 1 個目錄刪除事件。如果使用過濾佇列的話，正常情況下會只產生乙個目錄刪除事件，這無疑大大減少了 inotify 事件的產生，從而減少 rsync 無謂的同步次數。
當然，這裡說的也不絕對。如果這 6 個事件分多次讀到進入佇列，那麼可能還沒來得及過濾，就已經被同步執行緒從佇列中取走同步了，但是這確實在一定程度上減少了刪除目錄時的同步通訊次數。
3、過濾佇列的第三個作用
它可以過濾監控目錄下的目錄。如果我們不想同步目錄下的某些目錄或者一些字尾的檔案，只需要在inotify啟動的時候，remove 掉那些不需監控的子目錄監控即可。對於不需要監控的子目錄，產生的檔案事件就會從載入同步佇列前過濾掉。如果使用 rsync 用 -exclude 引數雖然也可以實現過濾，但是還要與 rsync 守護程序進行了一次互動才行。
下面是一些關於 inotfy識別事件和 sersync 的資料博文，大家可以去看一看：
sersync實現實時同步
環境準備 主機名外網ip 內網ip 角色部署服務 web01 10.0.0.7 172.16.1.7 rsync的客戶端，nfs的客戶端，rsync，nfs，apache，php web02 10.0.0.8 172.16.1.8 rsync的客戶端，nfs的客戶端，rsync，nfs，apache...
基於sersync海量檔案實時同步
基於sersync海量檔案實時同步 專案需求 最近涉及到數百萬張從本地儲存遷移到雲儲存，為了使完成遷移，並保證無缺失，業務不中斷，決定採用實時同步，同步完後再做流量切換。在實時同步方案中進行了幾種嘗試。方案1 rsync inotify同步，最先想到的是此方案，先看下指令碼 此前在多台伺服器間同步 ...
sersync實時同步服務部署
實驗環境 centos7.6,2g記憶體,50g硬碟大小,虛擬機器服務端ip 172.16.1.31 客戶端ip 172.16.1.41 1 需要部署好rsync守護程序服務，實現資料傳輸 2 需要部署好inotify服務，實現目錄中資料變化監控 3 將rsync服務和inotify服務建立聯絡，將...