（六）FastDFS 高可用叢集架構學習---後期運維--組內機器間資料同步（摘錄）
一、Binlog同步概述
FastDFS中為了維護檔案的多個副本，會在同組的Storage之間互相同步檔案，也就是一個備份過程，若一組有三臺機器，那麼互相備份後，一個檔案就有三個副本。本篇將主要描述Binlog同步的相關概念，與同步邏輯，以及一些注意事項。
1、Binlog結構
1）目錄結構
在Storage.conf配置檔案中，有一個配置如下：base_path=/data/zcs/fdfs_Storage_base
在Storaged程式啟動時會建立一個 base_path/data/sync 目錄，該目錄中的檔案都是和Storaged之間的同步相關的，如：
10.0.1.1_23000.mark10.0.1.2_23000.mark binlog.000binlog.index
binlog.index ##記錄當前使用的Binlog檔案序號，如為1，則表示使用binlog.001
binlog.000##真實地Binlog檔案
10.0.1.1_23000.mark##同步狀態檔案，記錄本機到10.0.1.1的同步狀態
2）Mark檔案內容描述
對於10.0.1.1_23000.mark檔案，本篇相關的內容有如下兩項：
binlog_index=0##表示上次同步給10.0.1.1機器的最後一條binlog檔案索引
binlog_offset=116##表示上次同步給10.0.1.1機器的最後一條binlog偏移量，若程式重啟了，也只要從這個位置開始向後同步即可。
3）Binlog檔案內容描述
對於binlog.000檔案，是有一條條binlog日誌組成的，如下：
1627025362 C M00/00/00/wKgDFGD6b9KALiDLAAYevEPlQIk376.jpg
1627025372 c M00/00/00/wKgDM2D6b9yAQJZxAAT4rd1P2iI703.jpg
1627025617 C M01/00/00/wKgDFGD6cNGAXGzwAAT4rd1P2iI215.jpg
1627025656 C M00/00/00/wKgDFGD6cPiAQED_AAT4rd1P2iI586.jpg
1627025654 c M01/00/00/wKgDM2D6cPaAC_vJAAT4rd1P2iI108.jpg
1627025657 c M00/00/00/wKgDM2D6cPmAZy_TAAT4rd1P2iI773.jpg
其中的每一條記錄都是使用空格符分成三個欄位，分別為：
第一部分：1627025362 表示檔案upload時間戳
第二部分：表示檔案建立方式
C表示源建立、c表示副本建立
A表示源追加、a表示副本追加
D表示源刪除、d表示副本刪除
T表示源Truncate、t表示副本Truncate
注：源表示客戶端直接操作的那個Storage即為源，其他的Storage都為副本，如客戶端向10.0.1.1主機Upload一個檔案，那麼在10.0.1.1機器上記錄的就是C，當10.0.1.1機器將該條binlog的操作同步給10.0.1.2時，在10.0.1.2上記錄的binlog就是c，其他幾種操作同理。
第三部分：檔案的FileID ：M01/00/00/wKgDFGD6cPqACGJNAAT4rd1P2iI332.jpg其中的M01為storepath索引，緊接著00/00/為路徑，後面wKgDFGD6cPqACGJNAAT4rd1P2iI332.jpg為檔案系統中實際的檔名（不採用合併儲存時，若採用合併儲存並不是一個實際的檔名）。
注：檔名組成：CgAHl1SJUR6AZqSHAAAF1vgN0rw59.conf，這個檔名中，除了conf為檔案字尾，CgAHl1SJUR6AZqSHAAAF1vgN0rw59這部分是一個base64編碼緩衝區，組成如下：
1、Storage_id（ip的數值型）
2、timestamp（建立時間）
3、file_size（若原始值為32位則前面加入一個隨機值填充，最終為64位）
4、crc32（檔案內容的檢驗碼）
二、Binlog同步過程
在FastDFS之中，每個Storaged之間的同步都是由一個獨立執行緒負責的，該執行緒中的所有操作都是以同步方式執行的。比如一組伺服器有A、B、C三臺機器，那麼在每臺機器上都有兩個執行緒負責同步，如A機器，執行緒1負責同步資料到B，執行緒2負責同步資料到C。
1、獲取組內的其他Storage資訊，並啟動同步執行緒
在Storage.conf配置檔案中，只配置了Tracker的IP地址，並沒有配置組內其他的Storage。因此同組的其他Storage必須從Tracker獲取。具體過程如下：
1）Storage啟動時為每一個配置的Tracker啟動一個執行緒負責與該Tracker的通訊。
2）預設每間隔30秒，與Tracker傳送一次心跳包，在心跳包的回覆中，將會有該組內的其他Storage資訊。
3）Storage獲取到同組的其他Storage資訊之後，為組內的每個其他Storage開啟一個執行緒負責同步。
2、同步執行緒執行過程
每個同步執行緒負責到一臺Storage的同步，以阻塞方式進行。
1）開啟對應Storage的mark檔案，如負責到10.0.1.1的同步則開啟10.0.1.1_23000.mark檔案，從中讀取binlog_index、binlog_offset兩個欄位值，如取到值為：1、100，那麼就開啟binlog.001檔案，seek到100這個位置。
2）進入一個while迴圈，嘗試著讀取一行，若讀取不到則睡眠等待。若讀取到一行，並且該行的操作方式為源操作，如C、A、D、T（大寫的都是），則將該行指定的操作同步給對方（非源操作不需要同步），同步成功後更新binlog_offset標誌，該值會定期寫入到10.0.1.1_23000.mark檔案之中。
3、同步前刪除
假如同步較為緩慢，那麼有可能在開始同步一個檔案之前，該檔案已經被客戶端刪除，此時同步執行緒將列印一條日誌，然後直接接著處理後面的Binlog。
三、Storage的最後最早被同步時間
這個標題有點拗口，先舉個例子：一組內有Storage-A、Storage-B、Storage-C三臺機器。對於A這臺機器來說，B與C機器都會同步Binlog（包括檔案）給他，A在接受同步時會記錄每臺機器同步給他的最後時間（也就是Binlog中的第一個欄位timpstamp）。比如B最後同步給A的Binlog-timestamp為100，C最後同步給A的Binlog-timestamp為200，那麼A機器的最後最早被同步時間就為100.
這個值的意義在於，判斷一個檔案是否存在某個Storage上。比如這裡A機器的最後最早被同步時間為100，那麼如果一個檔案的建立時間為99，就可以肯定這個檔案在A上肯定有。為什呢？一個檔案會Upload到組內三臺機器的任何一臺上：
1）若這個檔案是直接Upload到A上，那麼A肯定有。
2）若這個檔案是Upload到B上，由於B同步給A的最後時間為100，也就是說在100之前的檔案都已經同步A了，那麼A肯定有。
3）同理C也一樣。
Storage會定期將每臺機器同步給他的最後時間告訴給Tracker，Tracker在客戶端要下載一個檔案時，需要判斷一個Storage是否有該檔案，只要解析檔案的建立時間，然後與該值作比較，若該值大於建立建立時間，說明該Storage存在這個檔案，可以從其下載。
Tracker也會定期將該值寫入到一個檔案之中，Storage_sync_timestamp.dat，內容如下：
group1,10.0.0.1,0,1408524351,1408524352
group1,10.0.0.2,1408524353,0,1408524354
group1,10.0.0.3,1408524355,1408524356,0
每一行記錄了，對應Storage同步給其他Storage的最後時間，如第一行表示10.0.0.1同步給10.0.0.2的最後時間為1408524351，同步給10.0.0.3的最後時間為1408524352；同理可以知道後面兩行的含義了。每行中間都有一個0，這個零表示自己同步給自己，沒有記錄。按照縱列看，取非零最小值就是最後最早同步時間了，如第三縱列為10.0.0.1被同步的時間，其中1408524353就是其最後最早被同步時間。
四、注意事項
1、由於到每臺機器的同步都是有單執行緒負責的，因此即使主機上有很多個磁碟也不能加快同步速度，因此單執行緒並不能最大化磁碟IO，最大的速度也就是一個磁碟的速度。
2、對於重要檔案，為了防止機器宕機或者壞磁碟的檔案丟失，及時的同步備份是必須得。若同步太慢，還可能導致Tracker不能正確估計可用空間，而導致空間溢位。
3、同步效能，由於Linux系統的檔案快取機制，若一個剛寫入的檔案馬上讀，那麼很可能就命中在系統快取上，此時讀資料幾乎不耗費時間，若不能命中快取，從磁碟讀，將耗費很長時間。因此寫入速度，最好與同步速度相當，這樣可以保證及時同步。若寫入速度超過同步速度，從某個時刻開始，將會使得所有的讀無法命中快取，同步效能將大幅下滑。