FastDFS的一些缺点(强烈需要注意)
2018年02月26日

数据安全性


1、写一份即成功:从源storage写完文件至同步到组内其他storage的时间窗口内,一旦源storage出现故障,就可能导致用户数据丢失,而数据的丢失对存储系统来说通常是不可接受的。


2、缺乏自动化恢复机制:当storage的某块磁盘故障时,只能换存磁盘,然后手动恢复数据;由于按机器备份,似乎也不可能有自动化恢复机制,除非有预先准备好的热备磁盘,缺乏自动化恢复机制会增加系统运维工作。


3、数据恢复效率低:恢复数据时,只能从group内其他的storage读取,同时由于小文件的访问效率本身较低,按文件恢复的效率也会很低,低的恢复效率也就意味着数据处于不安全状态的时间更长。


4、缺乏多机房容灾支持:目前要做多机房容灾,只能额外做工具来将数据同步到备份的集群,无自动化机制。


5、存储空间利用率

单机存储的文件数受限于inode数量

每个文件对应一个storage本地文件系统的文件,平均每个文件会存在block_size/2的存储空间浪费。

文件合并存储能有效解决上述两个问题,但由于合并存储没有空间回收机制,删除文件的空间不保证一定能复用,也存在空间浪费的问题。


6、负载均衡

group机制本身可用来做负载均衡,但这只是一种静态的负载均衡机制,需要预先知道应用的访问特性;同时group机制也导致不可能在group之间迁移数据来做动态负载均衡。


7、其他:

1)不支持POSIX通用接口访问,通用性较低

2)对跨公网的文件同步,存在较大延迟,需要应用做相应的容错策略

3)同步机制不支持文件正确性校验,降低了系统的可用性

4)通过API下载,存在单点的性能瓶颈


8、最最重要的一项:

1、几乎没有人维护,官方200多个isuees,很多bug从2014年至今都无人解决。

2、社区极不活跃,只有2个参与开发的contributors。

3、源码几乎无注释,代码写法偏个人风格,可维护性较差。

基于这点考虑,除非公司有人能读懂fastdfs源码,能做二次开发,否则这么多bug和待改进项,确实让人不安心。


随便摘几个issues大家看看:

  1. 部分storage节点文件缺失,访问时没有重定向到存在文件的storage节点;

  2. recv data fail or response status != 0, errno: 22, error info: Invalid argument

  3. file: tracker_proto.c, line: 48 response status 2 != 0

  4. storage目录建立在映射盘上,导致free storage为负数,从而无法上传文件

  5. 下载文件时偶发的会连接到没有该文件的Storage节点去下载

  6. file: storage_nio.c, line: 436, send timeout 大并发情况下出现以上问题

  7. 生产系统故障,文件同步失败导致无法上传问题


具体可以参考 对比 TFS,GFS,HBase等,比如:

http://blog.chinaunix.net/uid-20196318-id-4453266.html