在前面幾篇文章中我們對fastdfs系統的概述、tracker server、storage server以及文件的上傳、下載、刪除等功能的介紹，
本文將對同一組的不同storage server之間的同步以及新增storage server的同步進行介紹。
fastdfs文件系統結構
fastdfs文件系統原理
從fastdfs文件系統結構中我們可以看出不管是上傳文件、刪除文件、修改文件及新增storager server，文件的同步都是同組
內多臺storager server之間進行的。下面我們看fastdfs文件系統開發者是怎麼描述同步機制的（來源於chinaunix）：
tracker server的配置文件中沒有出現storage server，而storage server的配置文件中會列舉出所有的tracker server。
這就決定了storage server和tracker server之間的連接由storage server主動發起，storage server爲每個tracker server啓動一個線程
進行連接和通訊。
tracker server會在內存中保存storage分組及各個組下的storage server，並將連接過自己的storage server及其分組
保存到文件中，以便下次重啓服務時能直接從本地磁盤中獲得storage相關信息。storage server會在內存中記錄本組的所有服務器，
並將服務器信息記錄到文件中。tracker server和storage server之間相互同步storage server列表：
1. 如果一個組內增加了新的storage server或者storage server的狀態發生了改變，tracker server都會將storage server列
表同步給該組內的所有storage server。以新增storage server爲例，因爲新加入的storage server主動連接tracker server，tracker
server發現有新的storage server加入，就會將該組內所有的storage server返回給新加入的storage server，並重新將該組的storage
server列表返回給該組內的其他storage server；
2. 如果新增加一臺tracker server，storage server連接該tracker server，發現該tracker server返回的本組storage server
列表比本機記錄的要少，就會將該tracker server上沒有的storage server同步給該tracker server。
同一組內的storage server之間是對等的，文件上傳、刪除等操作可以在任意一臺storage server上進行。文件同步
只在同組內的storage server之間進行，採用push方式，即源服務器同步給目標服務器。以文件上傳爲例，假設一個組內有3臺storage
server A、B和C，文件F上傳到服務器B，由B將文件F同步到其餘的兩臺服務器A和C。我們不妨把文件F上傳到服務器B的操作爲源頭操
作，在服務器B上的F文件爲源頭數據；文件F被同步到服務器A和C的操作爲備份操作，在A和C上的F文件爲備份數據。同步規則總結如下：
1. 只在本組內的storage server之間進行同步；
2. 源頭數據才需要同步，備份數據不需要再次同步，否則就構成環路了；
3. 上述第二條規則有個例外，就是新增加一臺storage server時，由已有的一臺storage server將已有的所有數據（包括源頭數據和
備份數據）同步給該新增服務器；
storage server有7個狀態，如下：
# FDFS_STORAGE_STATUS_INIT :初始化，尚未得到同步已有數據的源服務器
# FDFS_STORAGE_STATUS_WAIT_SYNC :等待同步，已得到同步已有數據的源服務器
# FDFS_STORAGE_STATUS_SYNCING :同步中
# FDFS_STORAGE_STATUS_DELETED :已刪除，該服務器從本組中摘除（注：本狀態的功能尚未實現）
# FDFS_STORAGE_STATUS_OFFLINE :離線
# FDFS_STORAGE_STATUS_ONLINE :在線，尚不能提供服務
# FDFS_STORAGE_STATUS_ACTIVE :在線，可以提供服務
當storage server的狀態爲FDFS_STORAGE_STATUS_ONLINE時，當該storage server向tracker server發起一次heart beat時，
tracker server將其狀態更改爲FDFS_STORAGE_STATUS_ACTIVE。
組內新增加一臺storage server A時，由系統自動完成已有數據同步，處理邏輯如下：
1. storage server A連接tracker server，tracker server將storage server A的狀態設置爲FDFS_STORAGE_STATUS_INIT。
storage server A詢問追加同步的源服務器和追加同步截至時間點，如果該組內只有storage server A或該組內已成功上傳的文件數爲0，
則沒有數據需要同步，storage server A就可以提供在線服務，此時tracker將其狀態設置爲FDFS_STORAGE_STATUS_ONLINE，否則
tracker server將其狀態設置爲FDFS_STORAGE_STATUS_WAIT_SYNC，進入第二步的處理；
2. 假設tracker server分配向storage server A同步已有數據的源storage server爲B。同組的storage server和tracker server
通訊得知新增了storage server A，將啓動同步線程，並向tracker server詢問向storage server A追加同步的源服務器和截至時間點。
storage server B將把截至時間點之前的所有數據同步給storage server A；而其餘的storage server從截至時間點之後進行正常同步，只
把源頭數據同步給storage server A。到了截至時間點之後，storage server B對storage server A的同步將由追加同步切換爲正常同步，
只同步源頭數據；
3. storage server B向storage server A同步完所有數據，暫時沒有數據要同步時，storage server B請求tracker server將
storage server A的狀態設置爲FDFS_STORAGE_STATUS_ONLINE；
4 當storage server A向tracker server發起heart beat時，tracker server將其狀態更改爲FDFS_STORAGE_STATUS_ACTIVE。
從上面的描述，我覺得作者描述的非常的清楚，讓我們這些使用者能夠非常容易理解。
同步時間管理
剛剛我們從上面瞭解了fastdfs文件系統中組內的多個storage server之間同步的機制，那文件同步是什麼時候進行呢？是文件上傳成功後，
其它的storage server纔開始同步，其它的storage server怎麼去感知，tracker server是怎麼通知storage server呢？
管理同步時間
當一個文件上傳成功後，客戶端馬上發起對該文件下載請求（或刪除請求）時，tracker是如何選定一個適用的存儲服務器呢？
其實每個存儲服務器都需要定時將自身的信息上報給tracker，這些信息就包括了本地同步時間（即，同步到的最新文件的時間戳）。
而tracker根據各個存儲服務器的上報情況，就能夠知道剛剛上傳的文件，在該存儲組中是否已完成了同步。在storage server中這些信息是
以Binlog文件的形式存在的。
Binlog文件
當Storaged server啓動時會創建一個 base_path/data/sync 同步目錄，該目錄中的文件都是和同組內的其它 Storaged server之間的
同步狀態文件，如192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.100（binlog.index）；
192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.000 binlog.index
binlog.index 記錄當前使用的Binlog文件序號，如爲10，則表示使用binlog.010
binlog.100真實地Binlog文件
192.168.1.2_33450.mark 同步狀態文件，記錄本機到192.168.1.2_33450的同步狀態
在Mark文件中內容：由binlog_index和binlog_offset兩項組成，以192.168.1.2_33450.mark爲例其中binlog_index表示上次同步192.168.
1.2機器的最後一條
binlog文件索引，binlog_offset表示上次同步192.168.1.2機器的最後一條binlog偏移量，如果程序重啓了，也只要從這個位置開始向後同步。
Binlog文件內容：在該文件中是以binlog日誌組成，比如：
1470292943 c M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg
1470292948 C M00/03/63/QkIPAFdWPUCAfiraAAG93gO_2Ew311.png
1470292954 d M00/03/62/QkIPAFdWOyeAO3eUAABvALuMG64183.jpg
1470292959 C M00/01/23/QUIPAFdVQZ2AL_o-AAAMRBAMk3s679.jpg
1470292964 c M00/03/62/QkIPAFdVOsCAcxeQAAGTdbQsdVs062.jpg
1470292969 c M00/03/62/QkIPAFdVOnKAXu1NAABq9pkfsms63.jpeg
1470293326 D M00/03/62/QkIPAFdVMnGAZYSZAABq9pkfsms33.jpeg
其中的每一條記錄都是使用空格符分成三個字段，分別爲：
第一個字段 表示文件upload時間戳 如：1470292943
第二個字段 表示文件執行操作，值爲下面幾種
C表示源創建、c表示副本創建
A表示源追加、a表示副本追加
D表示源刪除、d表示副本刪除
T表示源Truncate、t表示副本Truncate
其中源表示客戶端直接操作的那個Storage即爲源，其他的Storage都爲副本
第三個字段 表示文件 如M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg
Storage server具體同步過程
從fastdfs文件同步原理中我們知道Storaged server之間的同步都是由一個獨立線程負責的，這個線程中的所有操作都是以同步方式
執行的。比如一組服務器有A、B、C三臺機器，那麼在每臺機器上都有兩個線程負責同步，如A機器，線程1負責同步數據到B，線程2負責同
步數據到C。每個同步線程負責到一臺Storage的同步，以阻塞方式進行。
以IP爲192.168.1.1的Storaged severe的服務器爲例，它的同步目錄下有192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.100
等文件現在Storaged severe將會從ip爲192.168.1.2的Storaged severe的存儲裏面同步數據。
1）打開對應Storage server的mark文件，如負責到192.168.1.1的同步則打開192.168.1.2_33450.mark 文件，從中讀取binlog_index、
binlog_offset兩個字段值，如取到值爲：100、1000，那麼就打開binlog.100文件，seek到1000這個位置。
2）進入一個while循環，嘗試着讀取一行，若讀取不到則睡眠等待。若讀取到一行，並且該行的操作方式爲源操作，如C、A、D、T
（大寫的都是），則將該行指定的操作同步給對方（非源操作不需要同步），同步成功後更新binlog_offset標誌，該值會定期寫入到192.168.1
.2_33450.mark文件之中。
同步過程中可能因爲同步較爲緩慢，導致可能在同步一個文件之前，文件已經被客戶端刪除，此時同步線程將打印一條日誌，然後直接處理後
面的Binlog。
注：本文的配圖和部分描述參考互聯網，Chinaunix FastDFS討論區和UC技術博客，如涉及版權問題，請聯繫我刪除。
