本文共 1709 字，大约阅读时间需要 5 分钟。
FastDFS是国人开发的一款分布式文件系统，目前社区比较活跃。系统中存在三种节点：Client、Tracker、Storage，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10，提升简单负载均衡、并发IO的性能、及数据的冗余备份；同时通过线性的添加新的逻辑存储组，从容实现存储容量的线性扩容。
文件下载上，除了支持通过API方式，目前还提供了apache和nginx的插件支持，同时也可以不使用对应的插件，直接以Web静态资源方式对外提供下载。目前FastDFS(V4.x)代码量大概6w多行，内部的网络模型使用比较成熟的libevent三方库，具备高并发的处理能力。
1）在上述介绍中Tracker服务器是整个系统的核心枢纽，其完成了访问调度(负载均衡)，监控管理Storage服务器，由此可见Tracker的作用至关重要，也就增加了系统的单点故障，为此FastDFS支持多个备用的Tracker，虽然实际测试发现备用Tracker运行不是非常完美，但还是能保证系统可用。
2）在文件同步上，只有同组的Storage才做同步，由文件所在的源Storage服务器push至其它Storage服务器，目前同步是采用Binlog方式实现，由于目前底层对同步后的文件不做正确性校验，因此这种同步方式仅适用单个集群点的局部内部网络，如果在公网上使用，肯定会出现损坏文件的情况，需要自行添加文件校验机制。
3）支持主从文件，非常适合存在关联关系的图片，在存储方式上，FastDFS在主从文件ID上做取巧，完成了关联关系的存储。
缺点
1）不支持断点续传，对大文件将是噩梦(FastDFS不适合大文件存储) 2）不支持POSIX通用接口访问，通用性较低 3）对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略 4）同步机制不支持文件正确性校验，降低了系统的可用性 5）通过API下载，存在单点的性能瓶颈从FastDFS的整个设计看，基本上都已简单为原则。比如以机器为单位备份数据，简化了tracker的管理工作；storage直接借助本地文件系统原样存储文件，简化了storage的管理工作；文件写单份到storage即为成功、然后后台同步，简化了写文件流程。但简单的方案能解决的问题通常也有限，FastDFS目前尚存在如下问题:
数据安全性：
写一份即成功：从源storage写完文件至同步到组内其他storage的时间窗口内，一旦源storage出现故障，就可能导致用户数据丢失，而数据的丢失对存储系统来说通常是不可接受的。 缺乏自动化恢复机制：当storage的某块磁盘故障时，只能换存磁盘，然后手动恢复数据；由于按机器备份，似乎也不可能有自动化恢复机制，除非有预先准备好的热备磁盘，缺乏自动化恢复机制会增加系统运维工作。 数据恢复效率低：恢复数据时，只能从group内其他的storage读取，同时由于小文件的访问效率本身较低，按文件恢复的效率也会很低，低的恢复效率也就意味着数据处于不安全状态的时间更长。 缺乏多机房容灾支持：目前要做多机房容灾，只能额外使用工具来将数据同步到备份的集群，无自动化机制。
存储空间利用率：
单机存储的文件数受限于inode数量 每个文件对应一个storage本地文件系统的文件，平均每个文件会存在block_size/2的存储空间浪费。 文件合并存储能有效解决上述两个问题，但由于合并存储没有空间回收机制，删除文件的空间不保证一定能复用，也存在空间浪费的问题
负载均衡：
group机制本身可用来做负载均衡，但这只是一种静态的负载均衡机制，需要预先知道应用的访问特性；同时group机制也导致不可能在group之间迁移数据来做动态负载均衡
转载地址：http://ombii.baihongyu.com/