fastdfs的个人空间
source link: https://my.oschina.net/u/3334339/blog/4951560
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK