Chinaunix

标题: FastDFS 3.0功能规划及方案设计 [打印本页]

作者: happy_fish100 时间: 2011-02-18 16:55
标题: FastDFS 3.0功能规划及方案设计
本帖最后由 happy_fish100 于 2011-04-11 17:58 编辑

海量小文件将严重影响系统的性能，主要是因为文件数过大，文件系统对文件寻址的开销比较大，这会导致文件系统性能低下，甚至导致死机等现象。
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 时间: 2011-02-18 17:54
本帖最后由 dxef 于 2011-02-18 18:11 编辑

人都说要先抢沙发再看帖

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

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

作者: happy_fish100 时间: 2011-02-19 15:17
本帖最后由 happy_fish100 于 2011-02-19 15:33 编辑

回复 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 时间: 2011-03-02 17:43
优化一下性能，fdfs存在较大的性能问题。我之前在1.x上做过一个简单的测试，就是上传10000个空文件，具体多少时间我不记得了，结果很一般。

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

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

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

作者: happy_fish100 时间: 2011-03-02 17:49
回复 4# koolcoy

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

作者: koolcoy 时间: 2011-03-02 17:52

回复 koolcoy

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

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

作者: happy_fish100 时间: 2011-04-11 18:00
V3.0正在开发中，目前进展比较顺利，预计5月份可以发布。
敬请期待。

作者: sealbird 时间: 2011-04-15 18:17

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

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

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

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

作者: fajaven2 时间: 2011-05-01 11:30
想请教下，改成合并小文件为 Block 后，与 TaobaoFS 有什么区别？

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

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

作者: happy_fish100 时间: 2011-05-01 17:42
回复 9# fajaven2

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

作者: liangfeng_mic 时间: 2011-06-05 16:49
版主您好：
对于海量小文件造成的文件寻址瓶颈，是否还可以有其它的解决方案，比如说选择高性能的文件系统；您认为FastDFS若部署于ReiserFS上，有可能突破文件寻址瓶颈吗？
谢谢！

作者: happy_fish100 时间: 2011-06-05 17:15
回复 11# liangfeng_mic

FastDFS V3.00采用的方案，是解决海量文件存取的应用级解决方案。是目前业界普遍采用的一种解决方案。
如果文件系统本身很好地解决了这个问题，当然是最好不过了。
你可以试试你所说的系统级解决方案。
另外，还有名叫xfs的文件系统，貌似性能也不错。

作者: happy_fish100 时间: 2011-08-14 16:28
FastDFS 3.0 于2011-06-19发布，目前最新版本是V3.01，欢迎大家使用，并反馈问题和建议。
要使用3.0的trunk特性，只需对tracker.conf中的几个配置项进行设置即可。
详情参见《FastDFS 配置文件详解》：http://bbs.chinaunix.net/thread-1941456-1-1.html

为了方便大家，摘录如下：
# if use a trunk file to store several small files
# default value is false
# since V3.00
use_trunk_file = false
# V3.0引入的参数。是否使用小文件合并存储特性，缺省是关闭的。

# the min slot size, should <= 4KB
# default value is 256 bytes
# since V3.00
slot_min_size = 256
# V3.0引入的参数。
# trunk file分配的最小字节数。比如文件只有16个字节，系统也会分配slot_min_size个字节。

# the max slot size, should > slot_min_size
# store the upload file to trunk file when it's size <= this value
# default value is 16MB
# since V3.00
slot_max_size = 16MB
# V3.0引入的参数。
# 只有文件大小<=这个参数值的文件，才会合并存储。如果一个文件的大小大于这个参数值，将直接保存到一个文件中（即不采用合并存储方式）。

# the trunk file size, should >= 4MB
# default value is 64MB
# since V3.00
trunk_file_size = 64MB
# V3.0引入的参数。
# 合并存储的trunk file大小，至少4MB，缺省值是64MB。不建议设置得过大。

作者: mikzh 时间: 2012-03-29 09:06
初次接触FastDFS，问几个题外话：

1. 团队配置如何，一旦出现问题，版本不再更新，大家岂不是要自己改源码？呵呵
2. 何时能提供python支持？
3. 跟TFS、Mongodb、hadoop比，Fdfs优势在哪块？

LZ能否抽点时间耐心解答一下，谢谢哈！

作者: eof007 时间: 2012-05-23 15:21
你好，我想用fastDFS来替换目前的邮件存储系统，邮件系统是每个邮件一个文件。trunkfile 功能很好，但对空间分配和释放算法不太明白，请教下：
trunkfile元数据是保存在trunkfile的开头head中吧？
在内存中是保存所有trunkfile的元数据吗？还是当一个trunkfile的free空间少于一定空间后，就不再insert，也不用保存到内存中，等delete后free空间达到一定值时再作为可选trunkfile？
关于trunkfile，内存中主要数据结构有哪些？按什么策略找到可插入的trunkfile？
能稍微详细讲下算法吗？谢谢

作者: happy_fish100 时间: 2012-05-23 17:02
本帖最后由 happy_fish100 于 2012-05-23 17:03 编辑

回复 15# eof007
一个group由一台stroage server承担trunk server的职责。
trunk server管理可用的trunk空间，通过AVL平衡二叉树来组织。
trunk file中，包括header和data区域两部分。header中记录文件占用的空间，文件后缀名等信息，紧接着是文件内容（data区域）。
文件被删除后，其占用空间回收到trunk server的可用空间中（作为一个结点插入到AVL tree），下次可以被重新分配利用。

作者: eof007 时间: 2012-05-23 17:32
回复 15# eof007
谢谢回复。
AVL树是只存在内存还是内存和硬盘都有？
文件平均只有10K，但数量达到10亿级别，频繁删除，能存储吗？
有存储大量小文件实际案例吗？
问得比较多，主要是具体算法不太清楚，测试环境不一定能反映生产环境情况，想从原理上多点了解，多点信心。
用于生产环境，还是要小心。

作者: happy_fish100 时间: 2012-05-23 17:44
本帖最后由 happy_fish100 于 2012-05-23 17:45 编辑

回复 17# eof007

>>AVL树是只存在内存还是内存和硬盘都有？
只保存在内存中。

>>文件平均只有10K，但数量达到10亿级别，频繁删除，能存储吗？
可以。可能需要分为多个group。

>>有存储大量小文件实际案例吗？
小文件合并存储这个特性是去年6月份发布的，目前还没有收到使用这个特性的用户反馈。

欢迎加入FastDFS技术交流群讨论：164684842

作者: happy_fish100 时间: 2012-07-22 15:04
自顶一下这个介绍性帖子，以方便大家查看。

作者: yier008 时间: 2012-07-22 16:01
版主老大，我非常想和你一起做这个事情，不知道有机会没啊

作者: yuanzh78 时间: 2012-07-23 10:25
楼上就想免费学习不给钱

作者: happy_fish100 时间: 2012-08-03 12:53
刚整理好的V3引入的小文件合并存储特性介绍PPT，欢迎大家下载阅读。
写得不清楚的地方，欢迎反馈和交流。

FastDFS V3合并存储特性介绍.rar

44.7 KB, 下载次数: 429

作者: guliny 时间: 2012-08-14 15:37
FastDFS技术交流群满了，：-（

作者: happy_fish100 时间: 2012-08-14 16:44
回复 23# guliny

群3还有空间，群号：212801927

作者: guliny 时间: 2012-08-24 11:39
好的，谢谢了，已经加上了

作者: zwleagle 时间: 2012-09-21 09:47

koolcoy 发表于 2011-03-02 17:52
这样才能测出fdfs的性能，如果上传大文件的话，系统瓶颈是网络和磁盘，上传空文件，系统瓶颈就是fdfs了， ...

FastDFS里面的通信方式都采用发送后都要阻塞的方式等待响应，肯定会影响性能。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)