FastDFS踩坑记

Posted 2021-08-31 Huazie

FastDFS踩坑记

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

分享几个收集到的FastDFS踩坑案例，供大家参考，以防掉进同一个坑里（欢迎在评论区补充踩坑案例）。

案例一

我在之前的公司碰到的案例，storage 只有一组共两台 server，已经挂载了三块硬盘。运维人员通过监控发现 storage server 磁盘空间快满了，于是决定挂载一块新硬盘进行扩容。运维人员扩容后我们发现一些文件访问不了，经过定位，发现其中一台服务器的原有挂载路径和硬盘发生了错配。重新挂载硬盘相对比较麻烦，于是我们调整配置文件 storage.conf 中的存储路径顺序后，问题解决。

再次强调： storage.conf中配置的存储路径顺序很重要（诸如store_path0、store_path1、store_path2等等），一旦配置好千万不能搞乱顺序，否则将导致文件访问不到的严重后果。

案例二

近期在 FastDFS 技术交流QQ群发生的血淋漓的配置错误惨案。两台 storage server 错误地配置了相同的网络文件存储路径，3年来一直相安无事。最近一次服务器重启，网络文件系统没有准备好的情况下，storage server 却先启动了。因为存储路径是空的，触发了 storage server 的单盘数据恢复，这台 storage server 从另外一台 storage server上拉取文件进行数据恢复。因为两台 storage server 使用了同一个网络共享存储，复制一个文件时就是读自己然后写自己。storage 数据恢复写文件采用了 truncate 模式（打开文件时将清空该文件），于是文件就被清空了。通过事后盘点，总共丢失近 2万 个文件，然后这位悲催的哥们想法设法进行文件恢复，不知道现在是否完全恢复了。

v6.02 对程序做了增强防止类似悲剧再次发生。当本地文件存在时，先写临时文件，文件复制成功后将临时文件改名为正式文件。

案例三

FastDFS Java SDK 中的 TrackerClient、StorageClient 和 StorageClient1 的实例（对象）均非多线程安全。有些同学已经踩到这个坑，我就不讲具体案例了，感兴趣的朋友可以在网上搜索相关资料。

最新的 FastDFS Java SDK 在以上三个类的注释中明确说明其非多线程安全的特性，希望能引起大家的重视，不要再掉进坑里。

解决多线程访问上述三个实例有两个常用方法：采用锁机制 或者 每次使用新生成的实例（对象）。

还有一个潜在的坑要给大家说明一下。StorageClient 和 StorageClient1 的几个构造方法中，务必谨慎使用指定 StorageServer 的构造方法（如非必要，请不要使用）。例如 StorageClient 的构造方法为：

// 这个构造方法是为上传文件到特定的storage server这一场景设计的，
// 其他场景请不要使用这个构造方法，或者将storageServer设置为null。
StorageClient(TrackerServer trackerServer, StorageServer storageServer)

大家在使用FastDFS的过程中碰到过什么样的坑，欢迎交流和分享。