本篇文章转载于 FastCFS 作者 余庆 大佬的 FastDFS分享与交流 公众号。
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 对账机制。
