fastDFS同步問題討論
一、文件同步延遲問題
前面也講過fastDFS同組內storage server數據是同步的， Storage server中由專門的線程根據binlog進行文件同步。為了最大程度地避免相互影響以及出於系統簡潔性考慮，Storage server對組內除自己以外的每台服務器都會啟動一個線程來進行文件同步。文件同步采用增量同步方式，系統記錄已同步的位置（binlog文件偏移量）到標識文件中。標識文件名格式：{dest storage IP}_{port}.mark，例如：192.168.1.14_23000.mark。Storage server采用binlog文件記錄文件上傳、刪除等更新操作。binlog中只記錄文件名，不記錄文件內容。文件同步只在同組內的Storage server之間進行，采用push方式，即源頭服務器同步給目標服務器。只有源頭數據才需要同步，備份數據並不需要再次同步，否則就構成環路了。有個例外，就是新增加一台Storage server時，由已有的一台Storage server將已有的所有數據（包括源頭數據和備份數據）同步給該新增服務器。客戶端將一個文件上傳到一台Storage server後，文件上傳工作就結束了。由Storage server根據binlog中的上傳記錄將這個文件同步到同組的其他Storage server。這樣的文件同步方式是異步方式，異步方式帶來了文件同步延遲的問題。新上傳文件後，在尚未被同步過去的Storage server上訪問該文件，會出現找不到文件的現象
二、FastDFS對文件同步延遲問題的解決方案
需要說明的是，一個組包含的Storage server不是通過配置文件設定的，而是通過Tracker server獲取到的。客戶端和Storage server主動連接Tracker server。Storage server主動向Tracker server報告其狀態信息，包括磁盤剩余空間、文件同步狀況、文件上傳下載次數等統計信息。Storage server會連接集群中所有的Tracker server，向他們報告自己的狀態。Storage server啟動一個單獨的線程來完成對一台Tracker server的連接和定時報告。另外，每台storage server都會定時向tracker server報告它向同組的其他storage server同步到的文件時間戳。當tracker server收到一台storage server的文件同步報告後，它會依次找出該組內各個storage server被同步到的文件時間戳最小值，作為storage的一個屬性記錄到內存中。根據上述情況fastDFS提供下面簡單解決方案：
1、和文件更新一樣，優先選擇源Storage server下載文件即可。這可以在Tracker server的配置文件中設置，對應的參數名為download_server。
2、選擇Storage server的方法是輪流選擇（round-robin）。當Client詢問Tracker server有哪些Storage server可以下載指定文件時，Tracker server返回滿足如下四個條件之一的Storage server：
a、該文件上傳到的源Storage server，文件直接上傳到該服務器上的；
b、文件創建時間戳 < Storage server被同步到的文件時間戳，這意味著當前文件已經被同步過來了；
c、文件創建時間戳=Storage server被同步到的文件時間戳，且（當前時間—文件創建時間戳） > 一個文件同步完成需要的最大時間（如5分鐘）；
d、（當前時間—文件創建時間戳） > 文件同步延遲阈值，比如我們把阈值設置為1天，表示文件同步在一天內肯定可以完成。
三、停止fastDFS服務
直接kill即可讓server進程正常退出，可以使用killall命令，例如：
killall fdfs_trackerd
killall fdfs_storaged
也可以使用FastDFS自帶的stop.sh腳本，如：
/usr/local/bin/stop.sh /usr/local/bin/fdfs_storaged /etc/fdfs/storage.conf
stop.sh只會停止命令行（包括參數）完全相同的進程。
但需要注意的是千萬不要使用-9參數強殺，否則可能會導致binlog數據丟失的問題。
四、fastDFS數據清空重整
停止storage server和tracker server，刪除base_path下的data子目錄即可。
