FastDFS合并存儲

1、海量小文件將嚴(yán)重影響系統(tǒng)的性能，主要是因為文件數(shù)過大，文件系統(tǒng)對文件尋址的開銷比較大，這會導(dǎo)致文件系統(tǒng)性能低下，甚至導(dǎo)致死機(jī)等現(xiàn)象。FastDFS 3.0將對小文件進(jìn)行優(yōu)化。使用業(yè)界普遍采用的做法，將多個小文件存儲到一個較大的文件中，比如64MB的文件，這個存儲實體文件不妨稱作trunk file。因為對小文件采用trunk file存儲方式，F(xiàn)astDFS 3.0將對trunk file可使用的區(qū)塊進(jìn)行管理，管理方式和內(nèi)存管理類似。對于大于一定大小的文件，比如閥值為trunk file size的4/5，則不再保存到trunk file中，直接保存為一個單獨的文件。storage serve

2、r內(nèi)置trunk manager的功能，在storage server上對trunk file可用區(qū)塊進(jìn)行管理。在一個時間點，一個group只有一臺storage server提供管理和查詢服務(wù)，簡稱trunk manager。該group的其余storage server作為備機(jī)，只接收binlog。如何做到一個group只有一臺storage server提供trunk管理服務(wù)，這個由tracker server統(tǒng)一協(xié)調(diào)完成。如果承擔(dān)trunk manager那臺storage server掛了，本組其余的一臺storage server會自動升級為trunk manager，接替其工作。

3、當(dāng)storage server要存儲一個小于閥值的文件（也就是小文件）時，先詢問trunk manager，trunk manager返回存儲到的trunk file文件名，以及存儲起始的偏移量。當(dāng)storage server成功完成文件存儲后，向trunk manager報告。如果報告失敗，則文件上傳當(dāng)失敗處理。trunk manager管理方案說明：trunk manager將trunk相關(guān)數(shù)據(jù)，全部存放到內(nèi)存中管理。對于trunk更新操作（包括增加和刪除兩種），會記錄到單獨的binlog文件中，有專門的線程將binlog文件同步給本組的其他storage server。為了節(jié)約內(nèi)存空間，

4、trunk file文件名，會單獨存放。trunk file可用空間鏈表中，trunk filename采用指針方式指向。當(dāng)storage server向trunk manager請求分配文件空間時，trunk manager會先在內(nèi)存中掃描有沒有滿足條件的可用trunk，如果有，那么直接返回。否則，創(chuàng)建一個trunk file，然后將新的trunk file記錄到binlog和內(nèi)存中，并完成分配。為了提高分配效率，trunk manager將采取slot的方式對可用空間進(jìn)行組織，比如初始的字節(jié)數(shù)為256，最大字節(jié)數(shù)為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 的以此類推。初次分配時，新創(chuàng)建的trunk file是在slot 32M中。隨著trunk file被逐漸使用，可能會從slot 32M移動到slot 16M中，后面又可能被移動到slot 1MB中，如此等等。每個slot下可用的空間信息，按可使用空間大小升序排列。這么做的好處是分配的效率會比較高，直接取第一個結(jié)點（鏈表頭）即可。為了簡潔起見

6、，不采用相鄰空閑空間合并機(jī)制。疑問解答：Q:就是說，每一組現(xiàn)在有了一臺專門用來接收文件的storage server？然后再向組內(nèi)其他server分發(fā)？這個算是單點了吧？那么，如果trunk server掛掉了，組內(nèi)其他storage server會升級成trunk server吧？升級過程是什么樣子的流程？A: 感謝LS的及時反饋。為了簡化，trunk server的確存在單點問題。為了減少單點風(fēng)險，trunk server會把更新binlog同步到同組的其他storage server上。萬一trunk server掛了，由tracker server來協(xié)調(diào)，選舉出新的trunk serv

7、er。新選舉出的trunk server，從binlog中加載已有數(shù)據(jù)，然后承擔(dān)trunk server的功能。判斷trunk server掛掉，有一定的超時機(jī)制。比如5分鐘內(nèi)，trunk server都處于離線狀態(tài)，則認(rèn)為trunk server掛掉。storage server升級為trunk server，由storage server主動申請的方式。多臺tracker server，按ip地址升序排列。storage server向第一臺tracker server申請成為trunk server，申請成功后，通知其他tracker server。Q:trunkfile元數(shù)據(jù)是保存在t

8、runkfile的開頭head中吧？在內(nèi)存中是保存所有trunkfile的元數(shù)據(jù)嗎？還是當(dāng)一個trunkfile的free空間少于一定空間后，就不再insert，也不用保存到內(nèi)存中，等delete后free空間達(dá)到一定值時再作為可選trunkfile？關(guān)于trunkfile，內(nèi)存中主要數(shù)據(jù)結(jié)構(gòu)有哪些？按什么策略找到可插入的trunkfile？能稍微詳細(xì)講下算法嗎？A:一個group由一臺stroage server承擔(dān)trunk server的職責(zé)。trunk server管理可用的trunk空間，通過AVL平衡二叉樹來組織。trunk file中，包括header和data區(qū)域兩部分。hea

9、der中記錄文件占用的空間，文件后綴名等信息，緊接著是文件內(nèi)容（data區(qū)域）。文件被刪除后，其占用空間回收到trunk server的可用空間中（作為一個結(jié)點插入到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樹是只存在內(nèi)存還是內(nèi)存和硬盤都有？文件平均只有10K，但數(shù)量達(dá)到10億級別，頻繁刪除，能存儲嗎？有存儲大量小文件實際案例嗎？問得比較多，主要是具體算法不太清楚，測試環(huán)境不一定能反映生產(chǎn)環(huán)境情況，想從原理上多點了解，多點信心。用于生產(chǎn)環(huán)境，還是要小心。A:>>AVL樹是只存在內(nèi)存還是內(nèi)存和硬盤都有？只保存在內(nèi)存中。>>文件平均只有10K，但數(shù)量達(dá)到10億級別，頻繁刪除，能存儲嗎？

11、可以?？赡苄枰譃槎鄠€group。>>有存儲大量小文件實際案例嗎？小文件合并存儲這個特性是去年6月份發(fā)布的，目前還沒有收到使用這個特性的用戶反饋。Q但是我把上傳的文件全部刪除完后，發(fā)現(xiàn)服務(wù)器上的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文件用啥接口可以刪除。我認(rèn)為這是fastdfs的一個BUG，理論上我將trunk文件中保存的小文件全部刪除完成后，fastdfs應(yīng)該自動清除trunk文件。A刪除文件后，trunk文件中的對應(yīng)的空間會釋放的。下次再上傳文件，就可以利用已經(jīng)釋放的空間。即使一個trunk文件中的所有文件都已經(jīng)被刪除，該trunk文件也不會被物理刪除掉。但其空間是可以被利用的。Q其中“current trunk file id = 140”值在上傳文件的過程中一直在增大，理論上來說，如果trunk文件內(nèi)容被刪除后，新上傳文件如果插入到了空的trunk文件中的話，這個值應(yīng)該不會成倍的增加才對呀，因為我每次都是上傳5110個文件，然后將其刪除，然后再重新上傳。每次上傳的文件都是一樣的。A這個現(xiàn)象和trunk內(nèi)文件空間分配策略有關(guān)。目前的分配策略，會導(dǎo)致釋放后的空間，不能被同樣大小的文件使用，而只能被小一些的文件使用。Q:看了介紹，3.x的fastdfs把許多小文件合并存儲在一個t