FastCFS binlog機制簡介

happy_fish100

​    FastCFS采用經典的Master/Slave結構及數據同步復制的做法。如果slave在線，master同步調用slave；否則slave將進入數據恢復階段，追上master的最新進度后，slave切換為在線狀態(tài)，此后master將數據同步復制到slave。

    FastCFS采用binlog記錄數據更改操作，binlog中不會記錄變更（如寫入）的文件內容，binlog相當于是數據索引，非常簡潔。FastCFS中binlog的兩大用途：一、實現數據索引持久化存儲，程序啟動時通過重放binlog加載數據索引；二、slave數據恢復時從master拉取缺失的binlog，然后基于該binlog進行數據恢復。大家直觀感受一下如下所示的binlog片段：

    第一列為更改時間（unix時間戳），第二列為數據版本號。多個數據副本的分布式系統(tǒng)要保證數據強一致性，就必須保證更改操作的順序。采用單調遞增的數據版本號，是嚴格保證更改順序的有效方法，這正是上一篇文章最后留下的懸念解答。

    FastCFS支持master失效時自動切換（failover），極端情況下發(fā)生master切換后，可能會導致原master和新master上的binlog部分數據不一致，而不一致的binlog數據只會在binlog文件的尾部，我們只需對最后N條（如3條）binlog進行校驗即可。如果slave最后N條binlog和master對賬失敗，slave會退出運行，需要人工修復binlog（通常只需刪除最后一條binlog）后該slave方可正常啟動。

    FastStore模塊有兩套binlog：用于slave數據恢復的replica binlog和用作數據索引的slice binlog。對于一次更新操作，先寫slice binlog，然后寫replica binlog。一次更新操作對應兩次binlog寫入，如何保證兩次寫入的事務性呢？FastCFS不允許寫binlog失敗，只有程序異常終止時（比如掉電、程序掛掉），二者才有可能不一致。因此寫入binlog時不做校驗，程序啟動時對兩個binlog進行對賬，去掉尾部多余的binlog記錄即可。

    FastCFS中master同步調用slave完成后才寫binlog，為什么不選擇在調用slave前寫binlog呢？master寫入binlog的時機是有講究的，這個問題就留給大家了。

    最后總結一下，FastCFS中binlog是保證數據一致性的重要機制，binlog自身做到一致性非常關鍵，FastCFS采用的是binlog對賬機制。