FastDFS 3.0功能规划及方案设计

happy_fish100

海量小文件将严重影响系统的性能，主要是因为文件数过大，文件系统对文件寻址的开销比较大，这会导致文件系统性能低下，甚至导致死机等现象。
FastDFS 3.0将对小文件进行优化。使用业界普遍采用的做法，将多个小文件存储到一个较大的文件中，比如64MB的文件，这个存储实体文件不妨称作trunk file。
因为对小文件采用trunk file存储方式，FastDFS 3.0将对trunk file可使用的区块进行管理，管理方式和内存管理类似。
对于大于一定大小的文件，比如阀值为trunk file size的4/5，则不再保存到trunk file中，直接保存为一个单独的文件。

storage server内置trunk manager的功能，在storage server上对trunk file可用区块进行管理。在一个时间点，一个group只有一台storage server提供管理和查询服务，简称trunk manager。该group的其余storage server作为备机，只接收binlog。
如何做到一个group只有一台storage server提供trunk管理服务，这个由tracker server统一协调完成。
如果承担trunk manager那台storage server挂了，本组其余的一台storage server会自动升级为trunk manager，接替其工作。

当storage server要存储一个小于阀值的文件（也就是小文件）时，先询问trunk manager，trunk manager返回存储到的trunk file文件名，以及存储起始的偏移量。当storage server成功完成文件存储后，向trunk manager报告。如果报告失败，则文件上传当失败处理。

trunk manager管理方案说明：
trunk manager将trunk相关数据，全部存放到内存中管理。对于trunk更新操作（包括增加和删除两种），会记录到单独的binlog文件中，有专门的线程将binlog文件同步给本组的其他storage server。
为了节约内存空间，trunk file文件名，会单独存放。trunk file可用空间链表中，trunk filename采用指针方式指向。

当storage server向trunk manager请求分配文件空间时，trunk manager会先在内存中扫描有没有满足条件的可用trunk，如果有，那么直接返回。否则，一个创建trunk file，然后将新的trunk file记录到binlog和内存中，并完成分配。

为了提高分配效率，trunk manager将采取slot的方式对可用空间进行组织，比如初始的字节数为256，最大字节数为32MB，每次以2倍的速度递增，形如：
256，512， 1K， 2K， 4K，。。。，1M，2M，4M，。。。，16M，32M
在slot 256中的可用空间，是 >= 256，< 512的
在slot 512中的可用空间，是 >= 512，< 1K的
在slot 1K中的可用空间，是 >= 1K，< 2K 的
以此类推。
初次分配时，新创建的trunk file是在slot 32M中。随着trunk file被逐渐使用，可能会从slot 32M移动到slot 16M中，后面又可能被移动到slot 1MB中，如此等等
每个slot下可用的空间信息，按可使用空间大小升序排列。这么做的好处是分配的效率会比较高，直接取第一个结点（链表头）即可。

为了简洁起见，不采用相邻空闲空间合并机制。

dxef

人都说要先抢沙发再看帖

就是说，每一组现在有了一台专门用来接收文件的storage server？然后再向组内其他server分发？这个算是单点了吧？

那么，如果trunk server挂掉了，组内其他storage server会升级成trunk server吧？升级过程是什么样子的流程？

happy_fish100

回复 2# dxef

感谢LS的及时反馈。
为了简化，trunk server的确存在单点问题。为了减少单点风险，trunk server会把更新binlog同步到同组的其他storage server上。
万一trunk server挂了，由tracker server来协调，选举出新的trunk server。新选举出的trunk server，从binlog中加载已有数据，然后承担trunk server的功能。
判断trunk server挂掉，有一定的超时机制。比如5分钟内，trunk server都处于离线状态，则认为trunk server挂掉。

storage server升级为trunk server，由storage server主动申请的方式。
多台tracker server，按ip地址升序排列。storage server向第一台tracker server申请成为trunk server，申请成功后，通知其他tracker server。

koolcoy

优化一下性能，fdfs存在较大的性能问题。我之前在1.x上做过一个简单的测试，就是上传10000个空文件，具体多少时间我不记得了，结果很一般。

ip地址在系统内部最好使用32位整数而不是字符串表示，fdfs在上传，下载一个文件的时候，ip地址在字符串和整数两种表示方法的相互转换过多，这个转换的时间消耗值得考虑。

一个组支持多于2台服务器的设计是多余的。因为实际部署中绝对没有人会这么部署，想一下，你会使用一个物理资源利用率才1/3的存储方案么？但是这个设计却让系统逻辑复杂了不少，建议去掉。

系统管理不方便，ssh几十台机器累死了都～～{:3_199:}

happy_fish100

回复 4# koolcoy

上传空文件，这种测试方法太极端了吧？！
集群系统管理这块，应该有专门的开源软件吧？

koolcoy

回复  koolcoy

上传空文件，这种测试方法太极端了吧？！
happy_fish100 发表于 2011-03-02 17:49

这样才能测出fdfs的性能，如果上传大文件的话，系统瓶颈是网络和磁盘，上传空文件，系统瓶颈就是fdfs了，这样就能看出来fdfs到底有多快{:3_190:}

happy_fish100

V3.0正在开发中，目前进展比较顺利，预计5月份可以发布。
敬请期待。

sealbird

--------------------------------------------------------------------------------



一个组支持多于2台服务器的设计是多余的。因为实际部署中绝对没有人会这么部署，想一下，你会使用一个物理资源利用率才1/3的存储方案么？但是这个设计却让系统逻辑复杂了不少，建议去掉。

系统管理不方便，ssh几十台机器累死了都～

这个我却认为是一个吸引我的设计点，为什么呢，这样做即可以做到冗余，还可以做到分流分压，不好吗

fajaven2

想请教下，改成合并小文件为 Block 后，与 TaobaoFS 有什么区别？

我是否可以认为，这么改之后， FastDFS是个 TFS 的简化版本？

我在考虑，是否要使用 FastDFS 还是 TFS。谢谢！

happy_fish100

回复 9# fajaven2

FastDFS 3.0主要是做小文件存储优化。
可能和TFS的做法类似吧。
预计5月份可以发布，敬请期待。