什么是文件系統(tǒng)

當(dāng)提到文件系統(tǒng)锻弓，大部分人都很陌生搓茬。但我們每個人幾乎每天都會使用到文件系統(tǒng)兽掰，比如大家打開 Windows、macOS 或者 Linux佳恬，不管是用資源管理器還是 Finder捏境，都是在和文件系統(tǒng)打交道毁葱。如果大家有自己動手裝過操作系統(tǒng)的話倾剿，第一次安裝的時候一定會有一個步驟就是要格式化磁盤前痘，格式化的時候就需要選擇磁盤需要用哪個文件系統(tǒng)坯癣。

維基百科上的關(guān)于文件系統(tǒng)的定義是：

In computing, file system is a method and data structure that the operating system uses to control how data is stored and retrieved.

簡而言之，文件系統(tǒng)管理的是某種物理存儲介質(zhì)（如磁盤、SSD绍绘、CD脯倒、磁帶等）上的數(shù)據(jù)。在文件系統(tǒng)中最基礎(chǔ)的概念就是文件和目錄悠反，所有的數(shù)據(jù)都會對應(yīng)一個文件，通過目錄以樹形結(jié)構(gòu)來管理和組織這些數(shù)據(jù)〉┪基于文件和目錄的組織結(jié)構(gòu)，可以進(jìn)行一些更高級的配置查辩，比如給文件配置權(quán)限、統(tǒng)計文件的大小、修改時間遣铝、限制文件系統(tǒng)的容量上限等。

以下羅列了一些在不同操作系統(tǒng)中比較常見的文件系統(tǒng)：

• Linux：ext4填硕、XFS壮莹、Btrfs
• Windows：NTFS命满、FAT32
• macOS：APFS、HFS+

上圖是 Linux 內(nèi)核的架構(gòu)，左邊 Virtual file system 區(qū)域铸磅，也就是虛擬文件系統(tǒng)簡稱 VFS。它的作用是為了幫助 Linux 去適配不同的文件系統(tǒng)而設(shè)計的，VFS 提供了通用的文件系統(tǒng)接口丘跌，不同的文件系統(tǒng)實現(xiàn)需要去適配這些接口闭树。

日常使用 Linux 的時候，所有的系統(tǒng)調(diào)用請求都會先到達(dá) VFS碍现，然后才會由 VFS 向下請求實際使用的文件系統(tǒng)悴晰。文件系統(tǒng)的設(shè)計者需要遵守 VFS 的接口協(xié)議來設(shè)計文件系統(tǒng)漂辐，接口是共享的袒啼，但是文件系統(tǒng)具體實現(xiàn)是不同的，每個文件系統(tǒng)都可以有自己的實現(xiàn)方式赦邻。文件系統(tǒng)再往下是存儲介質(zhì)按声，會根據(jù)不同的存儲介質(zhì)再去組織存儲的數(shù)據(jù)形式铐料。

上圖是一次寫操作的請求流程柒凉，在 Linux 里寫文件愧沟，其實就是一次 write() 系統(tǒng)調(diào)用。當(dāng)你調(diào)用 write() 操作請求的時候北启，它會先到達(dá) VFS，再由 VFS 去調(diào)用文件系統(tǒng)，最后再由文件系統(tǒng)去把實際的數(shù)據(jù)寫到本地的存儲介質(zhì)。

上圖是一個目錄樹的結(jié)構(gòu)，在文件系統(tǒng)里面，所有數(shù)據(jù)的組織形式都是這樣一棵樹的結(jié)構(gòu)项秉，從最上面的根節(jié)點(diǎn)往下，有不同的目錄和不同的文件。這顆樹的深度是不確定的，相當(dāng)于目錄的深度是不確定的，是由每個用戶來決定的，樹的葉子節(jié)點(diǎn)就是每一個文件目溉。

最右邊的 inode 就是每個文件系統(tǒng)內(nèi)部的數(shù)據(jù)結(jié)構(gòu)。這個 inode 有可能是一個目錄，也有可能是一個普通的文件星虹。 Inode 里面會包含關(guān)于文件的一些元信息护糖，比如創(chuàng)建時間、創(chuàng)建者颜及、屬于哪個組以及權(quán)限信息俏站、文件大小等讯蒲。此外每個 inode 里面還會有一些指針或者索引指向?qū)嶋H物理存儲介質(zhì)上的數(shù)據(jù)塊。
以上就是實際去訪問一個單機(jī)文件系統(tǒng)時肄扎，可能會涉及到的一些數(shù)據(jù)結(jié)構(gòu)和流程墨林。作為一個引子赁酝，讓大家對于文件系統(tǒng)有一個比較直觀的認(rèn)識。

分布式文件系統(tǒng)架構(gòu)設(shè)計

單機(jī)的文件系統(tǒng)已經(jīng)能夠滿足我們大部分使用場景的需求旭等，管理很多日常需要存儲的數(shù)據(jù)酌呆。但是隨著時代的發(fā)展以及數(shù)據(jù)的爆發(fā)增對于數(shù)據(jù)存儲的需求也是在不斷的增長，分布式文件系統(tǒng)應(yīng)運(yùn)而生辆雾。

上面列了一些大家相對比較熟悉或者使用比較多的分布式文件系統(tǒng)肪笋，這里面有開源的文件系統(tǒng)，也有公司內(nèi)部使用的閉源產(chǎn)品度迂。從這張圖可以看到一個非常集中的時間點(diǎn)藤乙，2000 年左右有一大批的分布式系統(tǒng)誕生，這些分布式文件系統(tǒng)至今在我們?nèi)粘９ぷ髦谢蚨嗷蛏龠€是會接觸到惭墓。在 2000 年之前也有各種各樣的共享存儲坛梁、并行文件系統(tǒng)、分布式文件系統(tǒng)腊凶，但基本上都是基于一些專用的且比較昂貴的硬件來構(gòu)建的划咐。

自 2003 年 Google 的 GFS（Google File System）論文公開發(fā)表以來，很大程度上影響了后面一大批分布式系統(tǒng)的設(shè)計理念和思想钧萍。GFS 證明了我們可以用相對廉價的通用計算機(jī)褐缠，來組建一個足夠強(qiáng)大、可擴(kuò)展风瘦、可靠的分布式存儲队魏，完全基于軟件來定義一個文件系統(tǒng)，而不需要依賴很多專有或者高昂的硬件資源万搔，才能去搭建一套分布式存儲系統(tǒng)胡桨。

因此 GFS 很大程度上降低了分布文件系統(tǒng)的使用門檻，所以在后續(xù)的各個分布式文件系統(tǒng)上都可以或多或少看到 GFS 的影子瞬雹。比如雅虎開源的 HDFS 它基本上就是按照 GFS 這篇論文來實現(xiàn)的昧谊，HDFS 也是目前大數(shù)據(jù)領(lǐng)域使用最廣泛的存儲系統(tǒng)。

上圖第四列的「POSIX 兼容」表示這個分布式文件系統(tǒng)對 POSIX 標(biāo)準(zhǔn)的兼容性酗捌。POSIX（Portable Operating System Interface）是用于規(guī)范操作系統(tǒng)實現(xiàn)的一組標(biāo)準(zhǔn)拣挪，其中就包含與文件系統(tǒng)有關(guān)的標(biāo)準(zhǔn)短绸。所謂 POSIX 兼容你辣，就是滿足這個標(biāo)準(zhǔn)里面定義的一個文件系統(tǒng)應(yīng)該具備的所有特征立轧，而不是只具備個別，比如 GFS草姻，它雖然是一個開創(chuàng)性的分布式文件系統(tǒng)钓猬，但其實它并不是 POSIX 兼容的文件系統(tǒng)。

Google 當(dāng)時在設(shè)計 GFS 時做了很多取舍撩独，它舍棄掉了很多傳統(tǒng)單機(jī)文件系統(tǒng)的特性敞曹，保留了對于當(dāng)時 Google 搜索引擎場景需要的一些分布式存儲的需求账月。所以嚴(yán)格上來說，GFS 并不是一個 POSIX 兼容的文件系統(tǒng)澳迫，但是它給了大家一個啟發(fā)局齿，還可以這樣設(shè)計分布式文件系統(tǒng)。

接下來我會著重以幾個相對有代表性的分布式文件系統(tǒng)架構(gòu)為例橄登，給大家介紹一下抓歼，如果要設(shè)計一個分布式文件系統(tǒng)，大概會需要哪些組件以及可能會遇到的一些問題拢锹。

GFS

首先還是以提到最多的 GFS 為例谣妻，雖然它在 2003 年就公布了，但它的設(shè)計我認(rèn)為至今也是不過時的卒稳，有很多值得借鑒的地方蹋半。GFS 的主要組件可以分為三塊，最左邊的 GFS client 也就是它的客戶端充坑，然后就是中間的 GFS master 也就是它的元數(shù)據(jù)節(jié)點(diǎn)减江，最下面兩塊是 GFS chunkserver 就是數(shù)據(jù)實際存儲的節(jié)點(diǎn)，master 和 chunkserver 之間是通過網(wǎng)絡(luò)來通信捻爷，所以說它是一個分布式的文件系統(tǒng)辈灼。Chunkserver 可以隨著數(shù)據(jù)量的增長不斷地橫向擴(kuò)展。

其中 GFS 最核心的兩塊就是 master 和 chunkserver也榄。我們要實現(xiàn)一個文件系統(tǒng)茵休，不管是單機(jī)還是分布式，都需要去維護(hù)文件目錄手蝎、屬性、權(quán)限俐芯、鏈接等信息棵介，這些信息是一個文件系統(tǒng)的元數(shù)據(jù)，這些元數(shù)據(jù)信息需要在中心節(jié)點(diǎn) master 里面去保存吧史。Master 也包含一個樹狀結(jié)構(gòu)的元數(shù)據(jù)設(shè)計邮辽。

當(dāng)要存儲實際的應(yīng)用數(shù)據(jù)時，最終會落到每一個 chunkserver 節(jié)點(diǎn)上贸营，然后 chunkserver 會依賴本地操作系統(tǒng)的文件系統(tǒng)再去存儲這些文件吨述。

Chunkserver 和 master、client 之間互相會有連接钞脂，比如說 client 端發(fā)起一個請求的時候揣云，需要先從 master 獲取到當(dāng)前文件的元數(shù)據(jù)信息，再去和 chunkserver 通信冰啃，然后再去獲取實際的數(shù)據(jù)邓夕。在 GFS 里面所有的文件都是分塊（chunk）存儲刘莹，比如一個 1GB 的大文件，GFS 會按照一個固定的大蟹俑铡（64MB）對這個文件進(jìn)行分塊点弯，分塊了之后會分布到不同的 chunkserver 上，所以當(dāng)你讀同一個文件時其實有可能會涉及到和不同的 chunkserver 通信矿咕。

同時每個文件的 chunk 會有多個副本來保證數(shù)據(jù)的可靠性抢肛，比如某一個 chunkserver 掛了或者它的磁盤壞了，整個數(shù)據(jù)的安全性還是有保障的碳柱，可以通過副本的機(jī)制來幫助你保證數(shù)據(jù)的可靠性捡絮。這是一個很經(jīng)典的分布式文件系統(tǒng)設(shè)計，現(xiàn)在再去看很多開源的分布式系統(tǒng)實現(xiàn)都或多或少有 GFS 的影子士聪。

這里不得不提一下锦援，GFS 的下一代產(chǎn)品: Colossus。由于 GFS 的架構(gòu)設(shè)計存在明顯的擴(kuò)展性問題剥悟，所以 Google 內(nèi)部基于 GFS 繼續(xù)研發(fā)了 Colossus灵寺。Colossus 不僅為谷歌內(nèi)部各種產(chǎn)品提供存儲能力，還作為谷歌云服務(wù)的存儲底座開放給公眾使用区岗。Colossus 在設(shè)計上增強(qiáng)了存儲的可擴(kuò)展性略板，提高了可用性，以處理大規(guī)模增長的數(shù)據(jù)需求慈缔。下面即將介紹的 Tectonic 也是對標(biāo) Colossus 的存儲系統(tǒng)叮称。篇幅關(guān)系，這篇博客不再展開介紹 Colossus藐鹤，有興趣的朋友可以閱讀官方博客瓤檐。

Tectonic

Tectonic 是 Meta（Facebook）內(nèi)部目前最大的一個分布式文件系統(tǒng)。Tectonic 項目大概在 2014 年就開始做了（之前被叫做 Warm Storage）娱节，但直到 2021 年才公開發(fā)表論文來介紹整個分布式文件系統(tǒng)的架構(gòu)設(shè)計挠蛉。

在研發(fā) Tectonic 之前，Meta 公司內(nèi)部主要使用 HDFS肄满、Haystack 和 f4 來存儲數(shù)據(jù)谴古，HDFS 用在數(shù)倉場景（受限于單集群的存儲容量，部署了數(shù)十個集群）稠歉，Haystack 和 f4 用在非結(jié)構(gòu)化數(shù)據(jù)存儲場景掰担。Tectonic 的定位即是在一個集群里滿足這 3 種存儲支撐的業(yè)務(wù)場景需求。和 GFS 一樣怒炸，Tectonic 也主要由三部分構(gòu)成带饱，分別是 Client Library、Metadata Store 和 Chunk Store阅羹。

Tectonic 比較創(chuàng)新的點(diǎn)在于它在 Metadata 這一層做了分層處理纠炮，以及存算分離的架構(gòu)設(shè)計 月趟。從架構(gòu)圖可以看到 Metadata 分了三層：Name layer、File layer 和 Block layer恢口。傳統(tǒng)分布式文件系統(tǒng)會把所有的元數(shù)據(jù)都看作同一類數(shù)據(jù)孝宗，不會把它們顯式區(qū)分。在 Tectonic 的設(shè)計中耕肩，Name layer 是與文件的名字或者目錄結(jié)構(gòu)有關(guān)的元數(shù)據(jù)因妇，F(xiàn)ile layer 是跟當(dāng)前文件本身的一些屬性相關(guān)的數(shù)據(jù)，Block layer 是每一個數(shù)據(jù)塊在 Chunk Store 位置的元數(shù)據(jù)猿诸。

Tectonic 之所以要做這樣一個分層的設(shè)計是因為它是一個非常大規(guī)模的分布式文件系統(tǒng)婚被，特別是在 Meta 這樣的量級下（EB 級數(shù)據(jù)）。在這種規(guī)模下梳虽，對于 Metadata Store 的負(fù)載能力以及擴(kuò)展性有著非常高的要求址芯。

第二點(diǎn)創(chuàng)新在于元數(shù)據(jù)的存算分離設(shè)計，前面提到這三個 layer 其實是無狀態(tài)的窜觉，可以根據(jù)業(yè)務(wù)負(fù)載去橫向擴(kuò)展谷炸。但是上圖中的 Key-value Store 是一個有狀態(tài)的存儲，layer 和 Key-value Store 之間通過網(wǎng)絡(luò)通信禀挫。

Key-value Store 并不完全是 Tectonic 自己研發(fā)的旬陡，而是用了 Meta 內(nèi)部一個叫做 ZippyDB 的分布式 KV 存儲來支持元數(shù)據(jù)的存儲。ZippyDB 是基于 RocksDB 以及 Paxos 共識算法來實現(xiàn)的一個分布式 KV 存儲语婴。Tectonic 依賴 ZippyDB 的 KV 存儲以及它提供的事務(wù)來保證整個文件系統(tǒng)元信息的一致性和原子性描孟。

這里的事務(wù)功能是非常重要的一點(diǎn)，如果要實現(xiàn)一個大規(guī)模的分布式文件系統(tǒng)砰左，勢必要把 Metadata Store 做橫向擴(kuò)展匿醒。橫向擴(kuò)展之后就涉及數(shù)據(jù)分片，但是在文件系統(tǒng)里面有一個非常重要的語義是強(qiáng)一致性缠导，比如重命名一個目錄青抛，目錄里面會涉及到很多的子目錄，這個時候要怎么去高效地重命名目錄以及保證重命名過程中的一致性酬核，是分布式文件系統(tǒng)設(shè)計中是一個非常重要的點(diǎn)，也是業(yè)界普遍認(rèn)為的難點(diǎn)适室。

Tectonic 的實現(xiàn)方案就是依賴底層的 ZippyDB 的事務(wù)特性來保證當(dāng)僅涉及單個分片的元數(shù)據(jù)時嫡意，文件系統(tǒng)操作一定是事務(wù)性以及強(qiáng)一致性的。但由于 ZippyDB 不支持跨分片的事務(wù)捣辆，因此在處理跨目錄的元數(shù)據(jù)請求（比如將文件從一個目錄移動到另一個目錄）時 Tectonic 無法保證原子性蔬螟。

在 Chunk Store 層 Tectonic 也有創(chuàng)新，上文提到 GFS 是通過多副本的方式來保證數(shù)據(jù)的可靠性和安全性汽畴。多副本最大的弊端在于它的存儲成本旧巾，比如說你可能只存了1TB 的數(shù)據(jù)耸序，但是傳統(tǒng)來說會保留三個副本，那么至少需要 3TB 的空間來存儲鲁猩，這樣使得存儲成本成倍增長坎怪。對于小數(shù)量級的文件系統(tǒng)可能還好，但是對于像 Meta 這種 EB 級的文件系統(tǒng)廓握，三副本的設(shè)計機(jī)制會帶來非常高昂的成本搅窿，所以他們在 Chunk Store 層使用 EC（Erasure Code）也就是糾刪碼的方式去實現(xiàn)。通過這種方式可以只用大概 1.2~1.5 倍的冗余空間隙券，就能夠保證整個集群數(shù)據(jù)的可靠性和安全性男应，相比三副本的冗余機(jī)制節(jié)省了很大的存儲成本。Tectonic 的 EC 設(shè)計細(xì)到可以針對每一個 chunk 進(jìn)行配置娱仔，是非常靈活的沐飘。

同時 Tectonic 也支持多副本的方式，取決于上層業(yè)務(wù)需要什么樣的存儲形式牲迫。EC 不需要特別大的的空間就可以保證整體數(shù)據(jù)的可靠性耐朴，但是 EC 的缺點(diǎn)在于當(dāng)數(shù)據(jù)損壞或丟失時重建數(shù)據(jù)的成本很高，需要額外消耗更多計算和 IO 資源恩溅。

通過論文我們得知目前 Meta 最大的 Tectonic 集群大概有四千臺存儲節(jié)點(diǎn)隔箍，總的容量大概有 1590PB，有 100 億的文件量脚乡，這個文件量對于分布式文件系統(tǒng)來說蜒滩，也是一個比較大的規(guī)模。在實踐中奶稠，百億級基本上可以滿足目前絕大部分的使用場景俯艰。

再來看一下 Tectonic 中 layer 的設(shè)計，Name锌订、File竹握、Block 這三個 layer 實際對應(yīng)到底層的 KV 存儲里的數(shù)據(jù)結(jié)構(gòu)如上圖所示。比如說 Name layer 這一層是以目錄 ID 作為 key 進(jìn)行分片辆飘，F(xiàn)ile layer 是通過文件 ID 進(jìn)行分片啦辐，Block layer 是通過塊 ID 進(jìn)行分片。

Tectonic 把分布式文件系統(tǒng)的元數(shù)據(jù)抽象成了一個簡單的 KV 模型蜈项，這樣可以非常好的去做橫向擴(kuò)展以及負(fù)載均衡芹关，可以有效防止數(shù)據(jù)訪問的熱點(diǎn)問題。

JuiceFS

JuiceFS 誕生于 2017 年紧卒，比 GFS 和 Tectonic 都要晚侥衬，相比前兩個系統(tǒng)的誕生年代，外部環(huán)境已經(jīng)發(fā)生了翻天覆地的變化。

首先硬件資源已經(jīng)有了突飛猛進(jìn)的發(fā)展轴总，作為對比直颅，當(dāng)年 Google 機(jī)房的網(wǎng)絡(luò)帶寬只有 100Mbps（數(shù)據(jù)來源：The Google File System 論文），而現(xiàn)在 AWS 上機(jī)器的網(wǎng)絡(luò)帶寬已經(jīng)能達(dá)到 100Gbps怀樟，是當(dāng)年的 1000 倍功偿！

其次云計算已經(jīng)進(jìn)入了主流市場，不管是公有云漂佩、私有云還是混合云脖含，企業(yè)都已經(jīng)邁入了「云時代」。而云時代為企業(yè)的基礎(chǔ)設(shè)施架構(gòu)帶來了全新挑戰(zhàn)投蝉，傳統(tǒng)基于 IDC 環(huán)境設(shè)計的基礎(chǔ)設(shè)施一旦想要上云养葵，可能都會面臨種種問題。如何最大程度上發(fā)揮云計算的優(yōu)勢是基礎(chǔ)設(shè)施更好融入云環(huán)境的必要條件瘩缆，固守陳規(guī)只會事倍功半关拒。

同時，GFS 和 Tectonic 都是僅服務(wù)公司內(nèi)部業(yè)務(wù)的系統(tǒng)庸娱，雖然規(guī)模很大着绊，但需求相對單一。而 JuiceFS 定位于服務(wù)廣大外部用戶熟尉、滿足多樣化場景的需求归露，因而在架構(gòu)設(shè)計上與這兩個文件系統(tǒng)也大有不同。

基于這些變化和差異斤儿，我們再來看看 JuiceFS 的架構(gòu)剧包。同樣的，JuiceFS 也是由 3 部分組成：元數(shù)據(jù)引擎往果、數(shù)據(jù)存儲和客戶端疆液。雖然大體框架上類似，但其實每一部分的設(shè)計 JuiceFS 都有著一些不太一樣的地方陕贮。

首先是數(shù)據(jù)存儲這部分堕油，相比 GFS 和 Tectonic 使用自研的數(shù)據(jù)存儲服務(wù)，JuiceFS 在架構(gòu)設(shè)計上順應(yīng)了云原生時代的特點(diǎn)肮之，直接使用對象存儲作為數(shù)據(jù)存儲掉缺。前面看到 Tectonic 為了存儲 EB 級的數(shù)據(jù)用了 4000 多臺服務(wù)器，可想而知戈擒，如此大規(guī)模存儲集群的運(yùn)維成本也必然不小眶明。對于普通用戶來說，對象存儲的好處是開箱即用峦甩、容量彈性，運(yùn)維復(fù)雜度陡然下降。對象存儲也支持 Tectonic 中使用的 EC 特性凯傲，因此存儲成本相比一些多副本的分布式文件系統(tǒng)也能降低不少犬辰。

但是對象存儲的缺點(diǎn)也很明顯，例如不支持修改對象冰单、元數(shù)據(jù)性能差幌缝、無法保證強(qiáng)一致性、隨機(jī)讀性能差等诫欠。這些問題都被 JuiceFS 設(shè)計的獨(dú)立元數(shù)據(jù)引擎涵卵，Chunk、Slice荒叼、Block 三層數(shù)據(jù)架構(gòu)設(shè)計轿偎，以及多級緩存解決了。

其次是元數(shù)據(jù)引擎被廓，JuiceFS 可使用一些開源數(shù)據(jù)庫作為元數(shù)據(jù)的底層存儲坏晦。這一點(diǎn)和 Tectonic 很像，但 JuiceFS 更進(jìn)了一步嫁乘，不僅支持分布式 KV昆婿，還支持 Redis、關(guān)系型數(shù)據(jù)庫等存儲引擎蜓斧，讓用戶可以靈活地根據(jù)自己的使用場景選擇最適合的方案仓蛆，這是基于 JuiceFS 定位為一款通用型文件系統(tǒng)所做出的架構(gòu)設(shè)計。使用開源數(shù)據(jù)庫的另一個好處是這些數(shù)據(jù)庫在公有云上通常都有全托管服務(wù)挎春，因此對于用戶來說運(yùn)維成本幾乎為零看疙。

前面提到 Tectonic 為了保證元數(shù)據(jù)的強(qiáng)一致性選擇了 ZippyDB 這個支持事務(wù)的 KV 存儲，但 Tectonic 也只能保證單分片元數(shù)據(jù)操作的事務(wù)性搂蜓，而 JuiceFS 對于事務(wù)性有著更嚴(yán)格的要求狼荞，需要保證全局強(qiáng)一致性（即要求跨分片的事務(wù)性）。因此目前支持的所有數(shù)據(jù)庫都必須具有單機(jī)或者分布式事務(wù)特性帮碰，否則是沒有辦法作為元數(shù)據(jù)引擎接入進(jìn)來的（一個例子就是 Redis Cluster 不支持跨 slot 的事務(wù)）相味。基于可以橫向擴(kuò)展的元數(shù)據(jù)引擎（比如 TiKV）殉挽，JuiceFS 目前已經(jīng)能做到在單個文件系統(tǒng)中存儲 200 多億個文件丰涉，滿足企業(yè)海量數(shù)據(jù)的存儲需求。

上圖是使用 KV 存儲（比如 TiKV）作為 JuiceFS 元數(shù)據(jù)引擎時的數(shù)據(jù)結(jié)構(gòu)設(shè)計斯碌，如果對比 Tectonic 的設(shè)計一死，既有相似之處也有一些大的差異。比如第一個 key傻唾，在 JuiceFS 的設(shè)計里沒有對文件和目錄進(jìn)行區(qū)分投慈，同時文件或目錄的屬性信息也沒有放在 value 里承耿，而是有一個單獨(dú)的 key 用于存儲屬性信息（即第三個 key）。

第二個 key 用于存儲數(shù)據(jù)對應(yīng)的塊 ID伪煤，由于 JuiceFS 基于對象存儲加袋，因此不需要像 Tectonic 那樣存儲具體的磁盤信息，只需要通過某種方式得到對象的 key 即可抱既。在 JuiceFS 的存儲格式中元數(shù)據(jù)分了 3 層：Chunk职烧、Slice、Block防泵，其中 Chunk 是固定的 64MiB 大小蚀之，所以第二個 key 中的 chunk_index 是可以通過文件大小、offset 以及 64MiB 直接計算得出捷泞。通過這個 key 獲取到的 value 是一組 Slice 信息足删，其中包含 Slice 的 ID、長度等肚邢，結(jié)合這些信息就可以算出對象存儲上的 key壹堰，最終實現(xiàn)讀取或者寫入數(shù)據(jù)。

最后有一點(diǎn)需要特別注意骡湖，為了減少執(zhí)行分布式事務(wù)帶來的開銷贱纠，第三個 key 在設(shè)計上需要靠近前面兩個 key，確保事務(wù)盡量在單個元數(shù)據(jù)引擎節(jié)點(diǎn)上完成响蕴。不過如果分布式事務(wù)無法避免谆焊，JuiceFS 底層的元數(shù)據(jù)引擎也支持（性能略有下降），確保元數(shù)據(jù)操作的原子性浦夷。

最后來看看客戶端的設(shè)計辖试。JuiceFS 和另外兩個系統(tǒng)最大的區(qū)別就是這是一個同時支持多種標(biāo)準(zhǔn)訪問方式的客戶端，包括 POSIX劈狐、HDFS罐孝、S3、Kubernetes CSI 等肥缔。GFS 的客戶端基本可以認(rèn)為是一個非標(biāo)準(zhǔn)協(xié)議的客戶端莲兢，不支持 POSIX 標(biāo)準(zhǔn)，只支持追加寫续膳，因此只能用在單一場景改艇。Tectonic 的客戶端和 GFS 差不多，也不支持 POSIX 標(biāo)準(zhǔn)坟岔，只支持追加寫谒兄，但 Tectonic 采用了一種富客戶端的設(shè)計，把很多功能都放在客戶端這一邊來實現(xiàn)社付，這樣也使得客戶端有著最大的靈活性承疲。此外 JuiceFS 的客戶端還提供了緩存加速特性邻耕，這對于云原生架構(gòu)下的存儲分離場景是非常有價值的。

結(jié)語

文件系統(tǒng)誕生于上個世紀(jì) 60 年代燕鸽，隨著時代的發(fā)展赊豌，文件系統(tǒng)也在不斷演進(jìn)。一方面由于互聯(lián)網(wǎng)的普及绵咱，數(shù)據(jù)規(guī)模爆發(fā)式增長，文件系統(tǒng)經(jīng)歷了從單機(jī)到分布式的架構(gòu)升級熙兔，Google 和 Meta 這樣的公司便是其中的引領(lǐng)者悲伶。

另一方面，云計算的誕生和流行推動著云上存儲的發(fā)展住涉，企業(yè)用云進(jìn)行備份和存檔已逐漸成為主流麸锉，一些在本地機(jī)房進(jìn)行的高性能計算、大數(shù)據(jù)場景舆声，也已經(jīng)開始向云端遷移花沉，這些對性能要求更高的場景給文件存儲提出了新的挑戰(zhàn)。JuiceFS 誕生于這樣的時代背景媳握，作為一款基于對象存儲的分布式文件系統(tǒng)碱屁，JuiceFS 希望能夠為更多不同規(guī)模的公司和更多樣化的場景提供可擴(kuò)展的文件存儲方案。

如有幫助的話歡迎關(guān)注我們項目 Juicedata/JuiceFS 喲蛾找！ (0?0?)