【正文】 單位進(jìn)行劃分，大小為64KB，每一個(gè)Block對(duì)應(yīng)一個(gè)32位的校驗(yàn)和?？偨Y(jié)：Master Server和Chunk Server都提供了相應(yīng)的容錯(cuò)機(jī)制，能實(shí)現(xiàn)完全自動(dòng)的容錯(cuò)處理和切換，響應(yīng)切換速度為秒級(jí)。其中前兩種元數(shù)據(jù)需要持久化到磁盤(pán)，chunk副本的位置信息不需要持久化，可以通過(guò)Chunk Server匯報(bào)獲取。Chunk的元信息包括全局唯一的ID，版本號(hào)，每個(gè)副本所在的Chunk Server編號(hào)，引用計(jì)數(shù)等。那么1PB數(shù)據(jù)的chunk元信息大小不超過(guò)1PB * 3 / 64MB * 64 = 3GB。壓縮存儲(chǔ)后，每個(gè)文件在文件名字空間的元數(shù)據(jù)也不超過(guò)64字節(jié)，由于GFS中的文件一般都是大文件，因此，文件名字空間占用內(nèi)存不多?？偨Y(jié)：為了提高性能，Master Server需要將部分元數(shù)據(jù)緩存到內(nèi)存，因此需要較大的內(nèi)存。. 負(fù)載均衡GFS中副本的分布策略需要考慮多種因素，如網(wǎng)絡(luò)的拓?fù)洌瑱C(jī)架的分布，磁盤(pán)的利用率等等。系統(tǒng)中有三種需要?jiǎng)?chuàng)建chunk副本的情況：chunk創(chuàng)建，chunk重新復(fù)制（rereplication）以及重新平衡（rebalancing）。（3）每個(gè)chunk的所有副本不能在同一個(gè)機(jī)架。當(dāng)Chunk的副本數(shù)量小于一定的數(shù)量后，Master會(huì)嘗試重新復(fù)制一個(gè)chunk副本。每一個(gè)chunk復(fù)制任務(wù)都有一個(gè)優(yōu)先級(jí)，按照優(yōu)先級(jí)從高到低在Master排隊(duì)等待執(zhí)行。最后，Master會(huì)定期掃描當(dāng)前副本的分布情況，如果發(fā)現(xiàn)磁盤(pán)使用量或者機(jī)器負(fù)載不均衡，將執(zhí)行重新平衡操作。總結(jié)：GFS的負(fù)載均衡策略十分完備，已被眾多開(kāi)源實(shí)現(xiàn)所模仿。Master定時(shí)檢查，如果發(fā)現(xiàn)文件刪除超過(guò)一段時(shí)間（默認(rèn)為3天，可配置），那么它會(huì)把文件從內(nèi)存元數(shù)據(jù)中刪除，以后Chunk Server和Master的心跳消息中，每一個(gè)Chunk Server都將報(bào)告自己的chunk集合，Master會(huì)回復(fù)在Master元數(shù)據(jù)中已經(jīng)不存在的chunk信息，這時(shí)，Chunk Server會(huì)釋放這些Chunk副本。另外，Chunk副本可能會(huì)因?yàn)镃hunk Server失效期間丟失了對(duì)Chunk的修改操作而導(dǎo)致過(guò)期。Master仍然通過(guò)正常的垃圾回收機(jī)制來(lái)刪除過(guò)期的副本。. 快照快照（Snapshot）操作是對(duì)源文件/目錄進(jìn)行一個(gè)”快照”操作，生成該時(shí)刻源文件/目錄的一個(gè)瞬間狀態(tài)存放與目標(biāo)文件/目錄中。為了對(duì)某個(gè)文件做Snapshot，首先需要停止這個(gè)文件的寫(xiě)服務(wù)，接著增加這個(gè)文件的所有chunk的引用計(jì)數(shù)，以后修改這些chunk時(shí)會(huì)拷貝生成新的chunk。Master首先需要收回C1，C2和C3的寫(xiě)Lease，從而保證文件foo處于一致的狀態(tài)，接著Master復(fù)制foo文件的元數(shù)據(jù)生成foo_backup，foo_backup同樣指向C1，C2和C3。以后客戶端再次往C3追加數(shù)據(jù)時(shí)，Master發(fā)現(xiàn)C3的引用計(jì)數(shù)大于1，通知C3所在的Chunk Server本次拷貝C3生成C3′，客戶端的追加操作也相應(yīng)地轉(zhuǎn)向C3′。. ChunkServerChunkServer管理大小均為64MB的chunk，存儲(chǔ)的時(shí)候需要保證chunk盡可能均勻地分布在不同的磁盤(pán)之中，可能考慮的因素包括磁盤(pán)空間，最近新建chunk數(shù)，等。ChunkServer是一個(gè)磁盤(pán)和網(wǎng)絡(luò)IO密集型應(yīng)用，為了最大限度地發(fā)揮機(jī)器性能，需要能夠做到將磁盤(pán)和網(wǎng)絡(luò)操作異步化，這會(huì)增加代碼實(shí)現(xiàn)的難度。 GFS并不是直接保存源文件，而是將文件分塊存儲(chǔ)。對(duì)于小文件，則實(shí)現(xiàn)方案不一。 ChunkServer的磁盤(pán)IO是瓶頸之一，采用追加方式，避免隨機(jī)寫(xiě)是比較普遍的解決方案。通過(guò)近期的學(xué)習(xí)，對(duì)于分布式文件系統(tǒng)，有了那么一些粗淺的體會(huì)。 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)是單機(jī)應(yīng)用的產(chǎn)物，分布式文件系統(tǒng)是當(dāng)前大數(shù)據(jù)應(yīng)用的主流。 容錯(cuò)機(jī)制、負(fù)載均衡、垃圾回收、數(shù)據(jù)一致性是云存儲(chǔ)的基本要求。216。大部分系統(tǒng)都有MasterServer的冗余備份，有的是主備機(jī)制，有的是平行機(jī)制。216。216。216。Java的移植性好，C的性能卓越。很不幸，出于性能的考慮，不少產(chǎn)品沒(méi)有實(shí)現(xiàn)POSIX或者FUSE，因而安裝上往往很不方便。3. 開(kāi)源的分布式文件存儲(chǔ)系統(tǒng). 前言開(kāi)源的分布式文件存儲(chǔ)系統(tǒng)非常多，也多有各自的用戶群體。本文優(yōu)先介紹那些流行的產(chǎn)品，但是我在調(diào)研過(guò)程深深感到，這個(gè)互聯(lián)網(wǎng)領(lǐng)域火熱的應(yīng)用發(fā)展實(shí)在太快了，相對(duì)來(lái)說(shuō)也太紛亂了些，今天總結(jié)的成果也許過(guò)段時(shí)間就變了，有更好的產(chǎn)品出現(xiàn)了。Hadoop包括很多模塊，其中HDFS是它的分布式文件存儲(chǔ)系統(tǒng)。HDFS的設(shè)計(jì)理念和GFS是高度一致的，因此，理解了GFS的架構(gòu)，你就能理解HDFS的架構(gòu)。 流行，幾乎所有流行的分布式系統(tǒng)都可以和HDFS進(jìn)行對(duì)接；強(qiáng)大的社區(qū)支持，資料完備齊全。 流式數(shù)據(jù)訪問(wèn)，設(shè)計(jì)中更多的考慮了數(shù)據(jù)批處理，而不是用戶交互處理。216。216。216。需要人工切換。216。216。216。216。. KFS開(kāi)發(fā)語(yǔ)言： C++，可用C++、Java和Python訪問(wèn)客戶端。因此和HDFS有這相同的架構(gòu)和特點(diǎn)。 KFS本身的性能優(yōu)于HDFS，但若集成到hadoop中，性能卻未必出色。 站在開(kāi)源角度，不及HDFS活躍。MDS可以擴(kuò)展，不存在瓶頸無(wú)，不存在單點(diǎn)故障。性能分析性能一般理論上優(yōu)于HDFS性能一般存在性能瓶頸性能很高，“窮人的解決方案”據(jù)說(shuō)性能不錯(cuò)據(jù)說(shuō)性能不錯(cuò)讀寫(xiě)操作一次寫(xiě)入，多次讀取可多次寫(xiě)，可以在任意位置寫(xiě)，也可以在文件尾append一次寫(xiě)入，多次讀取一次寫(xiě)入，多次讀取一次寫(xiě)入，多次讀取可多次寫(xiě)，可以在任意位置寫(xiě)，也可以在文件尾append一次寫(xiě)入，多次讀取安裝和移植安裝簡(jiǎn)便Java應(yīng)用，容易移植安裝比較簡(jiǎn)便只能在有限的linux版本上可用其它特點(diǎn)支持快照已經(jīng)進(jìn)入Linux內(nèi)核，前景光明其它缺陷不支持快照（在計(jì)劃中）不支持用戶磁盤(pán)配額和訪問(wèn)權(quán)限控制，也不支持硬鏈接和軟鏈接Master很耗內(nèi)存還不成熟，不適合生產(chǎn)環(huán)境由于沒(méi)有元數(shù)據(jù)服務(wù)器，因此增加了客戶端的負(fù)載，占用相當(dāng)?shù)腃PU和內(nèi)存。因此不建議使用較深的路徑。適合以文件為載體的在線服務(wù)，如相冊(cè)網(wǎng)站、視頻網(wǎng)站等等。重量級(jí)產(chǎn)品，不適合我們作為消息隊(duì)列，不能提供優(yōu)先級(jí)等功能作為消息隊(duì)列，不能提供優(yōu)先級(jí)功能開(kāi)源支持適用場(chǎng)景適合大文件適合作為消息隊(duì)列適合作為消息隊(duì)列. 開(kāi)源分布式文件存儲(chǔ)學(xué)習(xí)總結(jié)雖然列出了多達(dá)11個(gè)分布式文件系統(tǒng)，但是還有眾多的產(chǎn)品沒(méi)有列出。 Spark,性能超Hadoop百倍，算法實(shí)現(xiàn)僅有其1/10或1/100216。 Sector/Sphere 比hadoop快24倍限于精力有限，這些產(chǎn)品沒(méi)有進(jìn)行調(diào)研和總結(jié)。4. 參考資料GFS：Hadoop：KFS：