當(dāng)提到文件系統(tǒng)時(shí)，大部分人都很陌生。但實(shí)際上我們幾乎每天都會(huì)使用它。比如，大家打開(kāi) Windows、macOS 或者 Linux，不管是用資源管理器還是 Finder，都是在和文件系統(tǒng)打交道。

如果大家曾經(jīng)手動(dòng)安裝過(guò)操作系統(tǒng)，一定會(huì)記得在第一次安裝時(shí)需要格式化磁盤，格式化時(shí)就需要為磁盤選擇使用哪個(gè)文件系統(tǒng)。

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

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

簡(jiǎn)而言之，文件系統(tǒng)的任務(wù)是管理存儲(chǔ)介質(zhì)（例如磁盤、SSD、CD、磁帶等）上的數(shù)據(jù)。

在文件系統(tǒng)中最基礎(chǔ)的概念就是文件和目錄，所有的數(shù)據(jù)都會(huì)對(duì)應(yīng)一個(gè)文件，通過(guò)目錄以樹(shù)形結(jié)構(gòu)來(lái)管理和組織這些數(shù)據(jù)。

基于文件和目錄的組織結(jié)構(gòu)，可以進(jìn)行一些更高級(jí)的配置，比如給文件配置權(quán)限、統(tǒng)計(jì)文件的大小、修改時(shí)間、限制文件系統(tǒng)的容量上限等。

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

? Linux：ext4、XFS、Btrfs

? Windows：NTFS、FAT32

? macOS：APFS、HFS+

（圖片來(lái)源：《Modern Operating Systems》10.2.5 小節(jié)）

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

日常使用 Linux 的時(shí)候，所有的系統(tǒng)調(diào)用請(qǐng)求都會(huì)先到達(dá) VFS，然后才會(huì)由 VFS 向下請(qǐng)求實(shí)際使用的文件系統(tǒng)。

文件系統(tǒng)的設(shè)計(jì)者需要遵守 VFS 的接口協(xié)議來(lái)設(shè)計(jì)文件系統(tǒng)，接口是共享的，但是文件系統(tǒng)具體實(shí)現(xiàn)是不同的，每個(gè)文件系統(tǒng)都可以有自己的實(shí)現(xiàn)方式。文件系統(tǒng)再往下是存儲(chǔ)介質(zhì)，會(huì)根據(jù)不同的存儲(chǔ)介質(zhì)再去組織存儲(chǔ)的數(shù)據(jù)形式。

一次寫操作的請(qǐng)求流程 （圖片來(lái)源：《Linux Kernel Development》第 13 章 Filesystem Abstraction Layer）

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

目錄樹(shù)（圖片來(lái)源：《Modern Operating Systems》4.2.2 小節(jié)）

上圖是一個(gè)目錄樹(shù)的結(jié)構(gòu)，在文件系統(tǒng)里面，所有數(shù)據(jù)的組織形式都是這樣一棵樹(shù)的結(jié)構(gòu)，從最上面的根節(jié)點(diǎn)往下，有不同的目錄和不同的文件。

這顆樹(shù)的深度是不確定的，相當(dāng)于目錄的深度是不確定的，是由每個(gè)用戶來(lái)決定的，樹(shù)的葉子節(jié)點(diǎn)就是每一個(gè)文件。

文件描述符與 inode

（圖片來(lái)源：《Modern Operating Systems》10.6.3 小節(jié)）

最右邊的 inode 就是每個(gè)文件系統(tǒng)內(nèi)部的數(shù)據(jù)結(jié)構(gòu)。這個(gè) inode 有可能是一個(gè)目錄，也有可能是一個(gè)普通的文件。Inode 里面會(huì)包含關(guān)于文件的一些元信息，比如創(chuàng)建時(shí)間、創(chuàng)建者、屬于哪個(gè)組以及權(quán)限信息、文件大小等。此外每個(gè) inode 里面還會(huì)有一些指針或者索引指向?qū)嶋H物理存儲(chǔ)介質(zhì)上的數(shù)據(jù)塊。

以上就是實(shí)際去訪問(wèn)一個(gè)單機(jī)文件系統(tǒng)時(shí)，可能會(huì)涉及到的一些數(shù)據(jù)結(jié)構(gòu)和流程。作為一個(gè)引子，讓大家對(duì)于文件系統(tǒng)有一個(gè)比較直觀的認(rèn)識(shí)。

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

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

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

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

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

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

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

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

GFS

（圖片來(lái)源：The Google File System 論文）

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

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

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

Chunkserver 和 master、client 之間互相會(huì)有連接，比如說(shuō) client 端發(fā)起一個(gè)請(qǐng)求的時(shí)候，需要先從 master 獲取到當(dāng)前文件的元數(shù)據(jù)信息，再去和 chunkserver 通信，然后再去獲取實(shí)際的數(shù)據(jù)。在 GFS 里面所有的文件都是分塊（chunk）存儲(chǔ)，比如一個(gè) 1GB 的大文件，GFS 會(huì)按照一個(gè)固定的大?。?4MB）對(duì)這個(gè)文件進(jìn)行分塊，分塊了之后會(huì)分布到不同的 chunkserver 上，所以當(dāng)你讀同一個(gè)文件時(shí)其實(shí)有可能會(huì)涉及到和不同的 chunkserver 通信。

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

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

Tectonic

（圖片來(lái)源：Facebook’s Tectonic Filesystem: Efficiency from Exascale 論文）

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

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

Tectonic 比較創(chuàng)新的點(diǎn)在于它在 Metadata 這一層做了分層處理，以及存算分離的架構(gòu)設(shè)計(jì)。從架構(gòu)圖可以看到 Metadata 分了三層：Name layer、File layer 和 Block layer。

傳統(tǒng)分布式文件系統(tǒng)會(huì)把所有的元數(shù)據(jù)都看作同一類數(shù)據(jù)，不會(huì)把它們顯式區(qū)分。在 Tectonic 的設(shè)計(jì)中，Name layer 是與文件的名字或者目錄結(jié)構(gòu)有關(guān)的元數(shù)據(jù)，F(xiàn)ile layer 是跟當(dāng)前文件本身的一些屬性相關(guān)的數(shù)據(jù)，Block layer 是每一個(gè)數(shù)據(jù)塊在 Chunk Store 位置的元數(shù)據(jù)。

Tectonic 之所以要做這樣一個(gè)分層的設(shè)計(jì)是因?yàn)樗且粋€(gè)非常大規(guī)模的分布式文件系統(tǒng)，特別是在 Meta 這樣的量級(jí)下（EB 級(jí)數(shù)據(jù)）。在這種規(guī)模下，對(duì)于 Metadata Store 的負(fù)載能力以及擴(kuò)展性有著非常高的要求。

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

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

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

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

在 Chunk Store 層 Tectonic 也有創(chuàng)新，上文提到 GFS 是通過(guò)多副本的方式來(lái)保證數(shù)據(jù)的可靠性和安全性。多副本最大的弊端在于它的存儲(chǔ)成本，比如說(shuō)你可能只存了1TB 的數(shù)據(jù)，但是傳統(tǒng)來(lái)說(shuō)會(huì)保留三個(gè)副本，那么至少需要 3TB 的空間來(lái)存儲(chǔ)，這樣使得存儲(chǔ)成本成倍增長(zhǎng)。

對(duì)于小數(shù)量級(jí)的文件系統(tǒng)可能還好，但是對(duì)于像 Meta 這種 EB 級(jí)的文件系統(tǒng)，三副本的設(shè)計(jì)機(jī)制會(huì)帶來(lái)非常高昂的成本，所以他們?cè)?Chunk Store 層使用 EC（Erasure Code）也就是糾刪碼的方式去實(shí)現(xiàn)。通過(guò)這種方式可以只用大概 1.2~1.5 倍的冗余空間，就能夠保證整個(gè)集群數(shù)據(jù)的可靠性和安全性，相比三副本的冗余機(jī)制節(jié)省了很大的存儲(chǔ)成本。Tectonic 的 EC 設(shè)計(jì)細(xì)到可以針對(duì)每一個(gè) chunk 進(jìn)行配置，是非常靈活的。

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

通過(guò)論文我們得知目前 Meta 最大的 Tectonic 集群大概有四千臺(tái)存儲(chǔ)節(jié)點(diǎn)，總的容量大概有 1590PB，有 100 億的文件量，這個(gè)文件量對(duì)于分布式文件系統(tǒng)來(lái)說(shuō)，也是一個(gè)比較大的規(guī)模。在實(shí)踐中，百億級(jí)基本上可以滿足目前絕大部分的使用場(chǎng)景。

（圖片來(lái)源：Facebook’s Tectonic Filesystem: Efficiency from Exascale 論文）

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

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

JuiceFS

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

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

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

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

基于這些變化和差異，我們?cè)賮?lái)看看 JuiceFS 的架構(gòu)。同樣的，JuiceFS 也是由 3 部分組成：元數(shù)據(jù)引擎、數(shù)據(jù)存儲(chǔ)和客戶端。雖然大體框架上類似，但其實(shí)每一部分的設(shè)計(jì) JuiceFS 都有著一些不太一樣的地方。

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

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

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

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

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

第二個(gè) key 用于存儲(chǔ)數(shù)據(jù)對(duì)應(yīng)的塊 ID，由于 JuiceFS 基于對(duì)象存儲(chǔ)，因此不需要像 Tectonic 那樣存儲(chǔ)具體的磁盤信息，只需要通過(guò)某種方式得到對(duì)象的 key 即可。在 JuiceFS 的存儲(chǔ)格式[3]中元數(shù)據(jù)分了 3 層：Chunk、Slice、Block，其中 Chunk 是固定的 64MiB 大小，所以第二個(gè) key 中的chunk_index是可以通過(guò)文件大小、offset 以及 64MiB 直接計(jì)算得出。通過(guò)這個(gè) key 獲取到的 value 是一組 Slice 信息，其中包含 Slice 的 ID、長(zhǎng)度等，結(jié)合這些信息就可以算出對(duì)象存儲(chǔ)上的 key，最終實(shí)現(xiàn)讀取或者寫入數(shù)據(jù)。

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

最后來(lái)看看客戶端的設(shè)計(jì)。JuiceFS 和另外兩個(gè)系統(tǒng)最大的區(qū)別就是這是一個(gè)同時(shí)支持多種標(biāo)準(zhǔn)訪問(wèn)方式的客戶端，包括 POSIX、HDFS、S3、Kubernetes CSI 等。GFS 的客戶端基本可以認(rèn)為是一個(gè)非標(biāo)準(zhǔn)協(xié)議的客戶端，不支持 POSIX 標(biāo)準(zhǔn)，只支持追加寫，因此只能用在單一場(chǎng)景。Tectonic 的客戶端和 GFS 差不多，也不支持 POSIX 標(biāo)準(zhǔn)，只支持追加寫，但 Tectonic 采用了一種富客戶端的設(shè)計(jì)，把很多功能都放在客戶端這一邊來(lái)實(shí)現(xiàn)，這樣也使得客戶端有著最大的靈活性。此外 JuiceFS 的客戶端還提供了緩存加速特性，這對(duì)于云原生架構(gòu)下的存儲(chǔ)分離場(chǎng)景是非常有價(jià)值的。

結(jié)語(yǔ)

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

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

審核編輯：劉清