Linux：ext4,、XFS、Btrfs

Windows：NTFS,、FAT32

macOS：APFS,、HFS+

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

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

日常使用 Linux 的時(shí)候，所有的系統(tǒng)調(diào)用請求都會(huì)先到達(dá) VFS,，然后才會(huì)由 VFS 向下請求實(shí)際使用的文件系統(tǒng),。文件系統(tǒng)的設(shè)計(jì)者需要遵守 VFS 的接口協(xié)議來設(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ù)形式,。

一次寫操作的請求流程

（圖片來源：《Linux Kernel Development》第 13 章 Filesystem Abstraction Layer）

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

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

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

文件描述符與 inode

（圖片來源：《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í)際去訪問一個(gè)單機(jī)文件系統(tǒng)時(shí),，可能會(huì)涉及到的一些數(shù)據(jù)結(jié)構(gòu)和流程,。作為一個(gè)引子，讓大家對于文件系統(tǒng)有一個(gè)比較直觀的認(rèn)識(shí),。

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

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

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

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

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

上圖第四列的「POSIX 兼容」表示這個(gè)分布式文件系統(tǒng)對 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è)開創(chuàng)性的分布式文件系統(tǒng)，但其實(shí)它并不是 POSIX 兼容的文件系統(tǒng),。

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

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

GFS

（圖片來源：The Google File System 論文）

首先還是以提到最多的 GFS 為例,，雖然它在 2003 年就公布了,，但它的設(shè)計(jì)我認(rèn)為至今也是不過時(shí)的，有很多值得借鑒的地方,。GFS 的主要組件可以分為三塊,，最左邊的 GFS client 也就是它的客戶端，然后就是中間的 GFS master 也就是它的元數(shù)據(jù)節(jié)點(diǎn),，最下面兩塊是 GFS chunkserver 就是數(shù)據(jù)實(shí)際存儲(chǔ)的節(jié)點(diǎn),，master 和 chunkserver 之間是通過網(wǎng)絡(luò)來通信，所以說它是一個(gè)分布式的文件系統(tǒng),。Chunkserver 可以隨著數(shù)據(jù)量的增長不斷地橫向擴(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è)樹狀結(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ì)有連接,，比如說 client 端發(fā)起一個(gè)請求的時(shí)候,，需要先從 master 獲取到當(dāng)前文件的元數(shù)據(jù)信息，再去和 chunkserver 通信,，然后再去獲取實(shí)際的數(shù)據(jù)。在 GFS 里面所有的文件都是分塊（chunk）存儲(chǔ),，比如一個(gè) 1GB 的大文件,，GFS 會(huì)按照一個(gè)固定的大小（64MB）對這個(gè)文件進(jìn)行分塊,，分塊了之后會(huì)分布到不同的 chunkserver 上,，所以當(dāng)你讀同一個(gè)文件時(shí)其實(shí)有可能會(huì)涉及到和不同的 chunkserver 通信。

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

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

Tectonic

（圖片來源：Facebook’s Tectonic Filesystem: Efficiency from Exascale 論文）

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

在研發(fā) Tectonic 之前,，Meta 公司內(nèi)部主要使用 HDFS,、Haystack 和 f4 來存儲(chǔ)數(shù)據(jù)，HDFS 用在數(shù)倉場景（受限于單集群的存儲(chǔ)容量,，部署了數(shù)十個(gè)集群）,，Haystack 和 f4 用在非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)場景。Tectonic 的定位即是在一個(gè)集群里滿足這 3 種存儲(chǔ)支撐的業(yè)務(wù)場景需求,。和 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ī)模下，對于 Metadata Store 的負(fù)載能力以及擴(kuò)展性有著非常高的要求,。

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

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

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

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

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

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

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

圖片（圖片來源：Facebook’s Tectonic Filesystem: Efficiency from Exascale 論文）

再來看一下 Tectonic 中 layer 的設(shè)計(jì),，Name,、File、Block 這三個(gè) layer 實(shí)際對應(yīng)到底層的 KV 存儲(chǔ)里的數(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ù)抽象成了一個(gè)簡單的 KV 模型,，這樣可以非常好的去做橫向擴(kuò)展以及負(fù)載均衡，可以有效防止數(shù)據(jù)訪問的熱點(diǎn)問題,。

JuiceFS

JuiceFS 誕生于 2017 年,，比 GFS 和 Tectonic 都要晚，相比前兩個(gè)系統(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ì)算已經(jīng)進(jìn)入了主流市場,，不管是公有云、私有云還是混合云,，企業(yè)都已經(jīng)邁入了「云時(shí)代」,。而云時(shí)代為企業(yè)的基礎(chǔ)設(shè)施架構(gòu)帶來了全新挑戰(zhàn)，傳統(tǒng)基于 IDC 環(huán)境設(shè)計(jì)的基礎(chǔ)設(shè)施一旦想要上云,，可能都會(huì)面臨種種問題,。如何最大程度上發(fā)揮云計(jì)算的優(yōu)勢是基礎(chǔ)設(shè)施更好融入云環(huán)境的必要條件，固守陳規(guī)只會(huì)事倍功半,。

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

圖片基于這些變化和差異，我們再來看看 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),，直接使用對象存儲(chǔ)作為數(shù)據(jù)存儲(chǔ)。前面看到 Tectonic 為了存儲(chǔ) EB 級(jí)的數(shù)據(jù)用了 4000 多臺(tái)服務(wù)器,，可想而知,，如此大規(guī)模存儲(chǔ)集群的運(yùn)維成本也必然不小。對于普通用戶來說,，對象存儲(chǔ)的好處是開箱即用,、容量彈性，運(yùn)維復(fù)雜度陡然下降,。對象存儲(chǔ)也支持 Tectonic 中使用的 EC 特性,，因此存儲(chǔ)成本相比一些多副本的分布式文件系統(tǒng)也能降低不少。

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

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

前面提到 Tectonic 為了保證元數(shù)據(jù)的強(qiáng)一致性選擇了 ZippyDB 這個(gè)支持事務(wù)的 KV 存儲(chǔ),，但 Tectonic 也只能保證單分片元數(shù)據(jù)操作的事務(wù)性，而 JuiceFS 對于事務(wù)性有著更嚴(yán)格的要求,，需要保證全局強(qiáng)一致性（即要求跨分片的事務(wù)性）,。因此目前支持的所有數(shù)據(jù)庫都必須具有單機(jī)或者分布式事務(wù)特性,，否則是沒有辦法作為元數(shù)據(jù)引擎接入進(jìn)來的（一個(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ì),，如果對比 Tectonic 的設(shè)計(jì)，既有相似之處也有一些大的差異,。比如第一個(gè) key,，在 JuiceFS 的設(shè)計(jì)里沒有對文件和目錄進(jìn)行區(qū)分，同時(shí)文件或目錄的屬性信息也沒有放在 value 里,，而是有一個(gè)單獨(dú)的 key 用于存儲(chǔ)屬性信息（即第三個(gè) key）,。

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

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

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

結(jié) 語

文件系統(tǒng)誕生于上個(gè)世紀(jì) 60 年代，隨著時(shí)代的發(fā)展,，文件系統(tǒng)也在不斷演進(jìn),。一方面由于互聯(lián)網(wǎng)的普及，數(shù)據(jù)規(guī)模爆發(fā)式增長,，文件系統(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ù)場景,，也已經(jīng)開始向云端遷移，這些對性能要求更高的場景給文件存儲(chǔ)提出了新的挑戰(zhàn),。JuiceFS 誕生于這樣的時(shí)代背景,，作為一款基于對象存儲(chǔ)的分布式文件系統(tǒng)，JuiceFS 希望能夠?yàn)楦嗖煌?guī)模的公司和更多樣化的場景提供可擴(kuò)展的文件存儲(chǔ)方案,。

關(guān)于作者

高昌健，Juicedata 技術(shù)專家,，參與建設(shè) JuiceFS 開源社區(qū)的主力隊(duì)員

引用鏈接

[1] 文件系統(tǒng): https://en./wiki/File_system

[2] 官方博客: https://cloud.google.com/blog/products/storage-data-transfer/a-peek-behind-colossus-googles-file-system

[3] 存儲(chǔ)格式: https:///docs/zh/community/architecture#how-juicefs-store-files