Fastdfs分散式檔案系統之檔案同步機制
原連結
http://blog.csdn.net/mr_smile2014/article/details/52118541
FastDFS同步相關檔案：
a)10.100.66.82_23000.mark
內容如下：
binlog_index=0
binlog_offset=1334
need_sync_old=1
sync_old_done=1
until_timestamp=1457542256
scan_row_count=23
sync_row_count=11
解釋：
binlog_index：對應於哪個binlog
binlog_offset：binlog.xxx的偏移量，可以直接這個偏移量獲取下一行記錄
need_sync_old：本storage是否是對側storage(10.100.66.82)的源結點，同時是否需要從起點同步所有的記錄
sync_old_done：是否同步完成過
until_timestamp：上次同步時間結點
scan_row_count：總記錄數
sync_row_count：已同步記錄數
b)binlog.000
內容如下
1457547668 C M00/00/00/CmRCUVbgaZSAGzKjAACkimfedYQ366.jpg
解釋：
1457547668：同步時間戳
C：標記檔案型別：C 源建立；A 源追加； D 源刪除； T 源Truncate。
對應的小寫字母則為副本，如c 副本建立。
M00/00/00/CmRCUVbgaZSAGzKjAACkimfedYQ366.jpg：檔名
c)binlog.index
內容如下
0
解釋：
現有binlog數。
新增結點同步流程圖
注意事項：
對於非源storage，只上傳指定時間結點後的原始檔給新增結點，副本檔案不處理。
對於源結點，需要把時間結點前所有檔案(源和副)傳給新結點。
同步完成後，B主動發訊息給tracker，修改tracker中A的狀態記錄。
A心跳獲取到tracker發過來的訊息，修改自身狀態。
Storage的狀態的主要意義，給tracker用來判定哪些active的結點可以服務。
啟動同步過程中，源結點狀態不改變，可以正常儲存檔案。
正常檔案同步流程圖
注意事項：
正常檔案上傳完成後，就記錄近binlog快取中，系統定時刷入binlog檔案。
系統有執行緒定時讀取binlog檔案，當有新增行時，判斷該記錄是原始檔記錄還是副本檔案記錄。
系統只主動傳送原始檔，副本檔案不做處理(非啟動時流程)。
圖中A的binlog中記錄的是源建立(C)，B中記錄的是副本建立(c)。
Storage的狀態
a)狀態值：
#define FDFS_STORAGE_STATUS_INIT 0 //初始狀態
#define FDFS_STORAGE_STATUS_WAIT_SYNC 1 b)啟動時狀態改變：
i.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_OFFLINE，否則tracker
server將其狀態設定為FDFS_STORAGE_STATUS_WAIT_SYNC，進入第二步的處理；
ii.假設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的同步將由追加同步切換為正常同步，只同步源頭資料；
iii.storage server B向storage server A同步完所有資料，暫時沒有資料要同步時，storage server B請求tracker server將storage server A的狀態設定為FDFS_STORAGE_STATUS_OFFLINE；
iv.當storage server A向tracker server發起heart beat時，tracker server將其狀態更改為FDFS_STORAGE_STATUS_ACTIVE。
Tracker選擇客戶端下載檔案的storage的原則
a)在同group下，獲取最小的一個同步時間點(各個storage在同一時間，同步完成的時間點不一樣)b)在最小同步時間點之前的檔案，按照使用者的規則隨意選擇一個storage。
c)在最小同步時間點之後的檔案，選擇源storage提供給客戶端。
本文將對同一組的不同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。