FastCFS采用经典的Master/Slave结构及数据同步复制的做法。如果slave在线，master同步调用slave；否则slave将进入数据恢复阶段，追上master的最新进度后，slave切换为在线状态，此后master将数据同步复制到slave。

    FastCFS采用binlog记录数据更改操作，binlog中不会记录变更（如写入）的文件内容，binlog相当于是数据索引，非常简洁。FastCFS中binlog的两大用途：一、实现数据索引持久化存储，程序启动时通过重放binlog加载数据索引；二、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源创计划”，欢迎正在阅读的你也加入，一起分享。