FastDFS合并存储

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

2、r内置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，接替其工作。

3、当storage server要存储一个小于阀值的文件（也就是小文件）时，先询问trunk manager，trunk manager返回存储到的trunk file文件名，以及存储起始的偏移量。当storage server成功完成文件存储后，向trunk manager报告。如果报告失败，则文件上传当失败处理。trunk manager管理方案说明：trunk manager将trunk相关数据，全部存放到内存中管理。对于trunk更新操作（包括增加和删除两种），会记录到单独的binlog文件中，有专门的线程将binlog文件同步给本组的其他storage server。为了节约内存空间，

4、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

5、，。，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下可用的空间信息，按可使用空间大小升序排列。这么做的好处是分配的效率会比较高，直接取第一个结点（链表头）即可。为了简洁起见

6、，不采用相邻空闲空间合并机制。疑问解答：Q:就是说，每一组现在有了一台专门用来接收文件的storage server？然后再向组内其他server分发？这个算是单点了吧？那么，如果trunk server挂掉了，组内其他storage server会升级成trunk server吧？升级过程是什么样子的流程？A: 感谢LS的及时反馈。为了简化，trunk server的确存在单点问题。为了减少单点风险，trunk server会把更新binlog同步到同组的其他storage server上。万一trunk server挂了，由tracker server来协调，选举出新的trunk serv

7、er。新选举出的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。Q:trunkfile元数据是保存在t

8、runkfile的开头head中吧？在内存中是保存所有trunkfile的元数据吗？还是当一个trunkfile的free空间少于一定空间后，就不再insert，也不用保存到内存中，等delete后free空间达到一定值时再作为可选trunkfile？关于trunkfile，内存中主要数据结构有哪些？按什么策略找到可插入的trunkfile？能稍微详细讲下算法吗？A:一个group由一台stroage server承担trunk server的职责。trunk server管理可用的trunk空间，通过AVL平衡二叉树来组织。trunk file中，包括header和data区域两部分。hea

9、der中记录文件占用的空间，文件后缀名等信息，紧接着是文件内容（data区域）。文件被删除后，其占用空间回收到trunk server的可用空间中（作为一个结点插入到AVL tree），下次可以被重新分配利用。Version 3.06  2012-01-22* add common/avl_tree.h and common/avl_tree.c* organize trunk free blocks using AVL tree* find the trunk server for each group when current tracker be a leader*

10、common/sched_thread.c can add schedule entry dynamicly* support creating trunk file advancelyQ:AVL树是只存在内存还是内存和硬盘都有？文件平均只有10K，但数量达到10亿级别，频繁删除，能存储吗？有存储大量小文件实际案例吗？问得比较多，主要是具体算法不太清楚，测试环境不一定能反映生产环境情况，想从原理上多点了解，多点信心。用于生产环境，还是要小心。A:>>AVL树是只存在内存还是内存和硬盘都有？只保存在内存中。>>文件平均只有10K，但数量达到10亿级别，频繁删除，能存储吗？

11、可以。可能需要分为多个group。>>有存储大量小文件实际案例吗？小文件合并存储这个特性是去年6月份发布的，目前还没有收到使用这个特性的用户反馈。Q但是我把上传的文件全部删除完后，发现服务器上的trunk文件无法删除。依然占用着磁盘空间。roothadoop 00# ls000001  000007  000013  000019  000025  000031  000037  000043  000049 &#

12、160;000055000002  000008  000014  000020  000026  000032  000038  000044  000050  000056000003  000009  000015  000021  000027  000033  000039 &#

13、160;000045  000051请问作者，这些trunk文件用啥接口可以删除。我认为这是fastdfs的一个BUG，理论上我将trunk文件中保存的小文件全部删除完成后，fastdfs应该自动清除trunk文件。A删除文件后，trunk文件中的对应的空间会释放的。下次再上传文件，就可以利用已经释放的空间。即使一个trunk文件中的所有文件都已经被删除，该trunk文件也不会被物理删除掉。但其空间是可以被利用的。Q其中“current trunk file id = 140”值在上传文件的过程中一直在增大，理论上来说，如果trunk文件内容被删除后，新上传文件如果插入到了空的trunk文件中的话，这个值应该不会成倍的增加才对呀，因为我每次都是上传5110个文件，然后将其删除，然后再重新上传。每次上传的文件都是一样的。A这个现象和trunk内文件空间分配策略有关。目前的分配策略，会导致释放后的空间，不能被同样大小的文件使用，而只能被小一些的文件使用。Q:看了介绍，3.x的fastdfs把许多小文件合并存储在一个t