FastCFS binlog機制簡介

    FastCFS採用經典的Master/Slave結構及數據同步複製的作法。若是slave在線，master同步調用slave；不然slave將進入數據恢復階段，追上master的最新進度後，slave切換爲在線狀態，此後master將數據同步複製到slave。

    FastCFS採用binlog記錄數據更改操做，binlog中不會記錄變動（如寫入）的文件內容，binlog至關因而數據索引，很是簡潔。FastCFS中binlog的兩大用途：1、實現數據索引持久化存儲，程序啓動時經過重放binlog加載數據索引；2、slave數據恢復時從master拉取缺失的binlog，而後基於該binlog進行數據恢復。你們直觀感覺一下以下所示的binlog片斷：

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

    FastCFS支持master失效時自動切換（failover），極端狀況下發生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對帳機制。

本文分享自微信公衆號 - FastDFS分享與交流（fastdfs100）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。