FastDFS是如何解决数据一致性问题的？

本篇文章转载于 FastDFS 作者 余庆 大佬的 FastDFS分享与交流 公众号。

保证数据一致性是分布式系统面临的最大难题，尤其是要做到数据强一致性。

FastDFS 作为一款分布式文件系统，是如何解决数据一致性的呢？

FastDFS 以简洁高效著称，其轻量级定位以及应用场景决定其不会采用复杂的解决方案。因此 FastDFS 放弃强一致性，采用弱一致性和最终一致的做法。

FastDFS 的 文件ID 是服务端生成的，其中包含了 storage ID或IP地址、文件创建时间、CRC32校验码、文件大小 和 随机数 等字段。

FastDFS 文件ID 的生成机制决定了可以在任意一台 storage server 上传文件而不用担心文件名和同组的其他 storage server 生成的文件冲突。

出于性能和简洁考虑，FastDFS 复制文件采用异步方式，这是保证数据最终一致的做法。

FastDFS 为了支持文件修改，引入了 appender 这一文件类型。FastDFS 支持对 appender 类型的文件进行修改和追加等操作。

如果在两台 storage server 上修改同一个 appender 文件（即使在顺序修改的情况下），可能就会因为时序问题导致数据不一致的现象发生。

为了解决这个问题，FastDFS 采取的做法是，对appender 文件的修改以及对文件的删除只能在 源storage server 上进行。

FastDFS 直接借助底层文件系统来存储和管理文件。

在文件复制过程中，为了避免应用端读到不完整的数据，storage server 采用先写临时文件，完成后再改名的做法。

为了保证数据完整性以及在异常情况下不覆盖上个版本的数据，tracker server 和storage server 写入重要的数据文件时，均采用了先写临时文件，然后改名的做法。

感谢你的阅读，希望 FastDFS 采用的数据一致性做法对你所有帮助和启发。