當(dāng)提到文件系統(tǒng)時(shí)芍殖，大部分人都很陌生。但實(shí)際上我們幾乎每天都會(huì)使用它。比如，大家打開 Windows、macOS 或者 Linux，不管是用資源管理器還是 Finder，都是在和文件系統(tǒng)打交道蜻底。如果大家曾經(jīng)手動(dòng)安裝過操作系統(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è)文件，通過目錄以樹形結(jié)構(gòu)來管理和組織這些數(shù)據(jù)。基于文件和目錄的組織結(jié)構(gòu)，可以進(jìn)行一些更高級(jí)的配置箱歧，比如給文件配置權(quán)限价淌、統(tǒng)計(jì)文件的大小、修改時(shí)間瞒津、限制文件系統(tǒng)的容量上限等蝉衣。
以下羅列了一些在不同操作系統(tǒng)中比較常見的文件系統(tǒng)：
? Linux：ext4、XFS巷蚪、Btrfs
? Windows：NTFS病毡、FAT32
-
? macOS：APFS、HFS+
微信圖片_20230311105340.png
（圖片來源：《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é)議來設(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)求流程（圖片來源：《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ì)童本。
目錄樹（圖片來源：《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è)引子，讓大家對(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)坡垫，這里面有開源的文件系統(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 證明了我們可以用相對(duì)廉價(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)對(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è)開創(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)格上來說积担，GFS 并不是一個(gè) POSIX 兼容的文件系統(tǒng)，但是它給了大家一個(gè)啟發(fā)猬仁，還可以這樣設(shè)計(jì)分布式文件系統(tǒng)帝璧。
接下來我會(huì)著重以幾個(gè)相對(duì)有代表性的分布式文件系統(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ù)量的增長(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è)樹狀結(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è)請(qǐng)求的時(shí)候侦啸，需要先從 master 獲取到當(dāng)前文件的元數(shù)據(jù)信息槽唾，再去和 chunkserver 通信丧枪，然后再去獲取實(shí)際的數(shù)據(jù)。在 GFS 里面所有的文件都是分塊（chunk）存儲(chǔ)庞萍，比如一個(gè) 1GB 的大文件拧烦，GFS 會(huì)按照一個(gè)固定的大小（64MB）對(duì)這個(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ī)模增長(zhǎng)的數(shù)據(jù)需求。下面即將介紹的 Tectonic 也是對(duì)標(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ù)倉(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í)是無狀態(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)辈挂，勢(shì)必要把 Metadata Store 做橫向擴(kuò)展衬横。橫向擴(kuò)展之后就涉及數(shù)據(jù)分片，但是在文件系統(tǒng)里面有一個(gè)非常重要的語(yǔ)義是強(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ù)請(qǐng)求（比如將文件從一個(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ǔ)成本成倍增長(zhǎng)硅卢。對(duì)于小數(shù)量級(jí)的文件系統(tǒng)可能還好射窒，但是對(duì)于像 Meta 這種 EB 級(jí)的文件系統(tǒng)，三副本的設(shè)計(jì)機(jī)制會(huì)帶來非常高昂的成本将塑，所以他們?cè)?Chunk Store 層使用 EC（Erasure Code）也就是糾刪碼的方式去實(shí)現(xiàn)脉顿。通過這種方式可以只用大概 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 資源。
通過論文我們得知目前 Meta 最大的 Tectonic 集群大概有四千臺(tái)存儲(chǔ)節(jié)點(diǎn)同廉，總的容量大概有 1590PB仪糖，有 100 億的文件量，這個(gè)文件量對(duì)于分布式文件系統(tǒng)來說迫肖，也是一個(gè)比較大的規(guī)模锅劝。在實(shí)踐中，百億級(jí)基本上可以滿足目前絕大部分的使用場(chǎng)景蟆湖。
（圖片來源：Facebook’s Tectonic Filesystem: Efficiency from Exascale 論文）
再來看一下 Tectonic 中 layer 的設(shè)計(jì)故爵，Name、File隅津、Block 這三個(gè) layer 實(shí)際對(duì)應(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è)簡(jiǎn)單的 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ā)展，作為對(duì)比确买，當(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)入了主流市場(chǎng)芭商，不管是公有云、私有云還是混合云搀缠，企業(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)勢(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è)賮砜纯?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ì)于普通用戶來說，對(duì)象存儲(chǔ)的好處是開箱即用、容量彈性溜在，運(yùn)維復(fù)雜度陡然下降陌知。對(duì)象存儲(chǔ)也支持 Tectonic 中使用的 EC 特性，因此存儲(chǔ)成本相比一些多副本的分布式文件系統(tǒng)也能降低不少掖肋。
但是對(duì)象存儲(chǔ)的缺點(diǎn)也很明顯仆葡，例如不支持修改對(duì)象、元數(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ù)庫(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ì)虹钮。使用開源數(shù)據(jù)庫(kù)的另一個(gè)好處是這些數(shù)據(jù)庫(kù)在公有云上通常都有全托管服務(wù)，因此對(duì)于用戶來說運(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ù)特性，否則是沒有辦法作為元數(shù)據(jù)引擎接入進(jìn)來的（一個(gè)例子就是 Redis Cluster 不支持跨 slot 的事務(wù)）岛都÷梢蹋基于可以橫向擴(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ì)里沒有對(duì)文件和目錄進(jìn)行區(qū)分，同時(shí)文件或目錄的屬性信息也沒有放在 value 里讯壶，而是有一個(gè)單獨(dú)的 key 用于存儲(chǔ)屬性信息（即第三個(gè) key）料仗。
第二個(gè) key 用于存儲(chǔ)數(shù)據(jù)對(duì)應(yīng)的塊 ID，由于 JuiceFS 基于對(duì)象存儲(chǔ)伏蚊，因此不需要像 Tectonic 那樣存儲(chǔ)具體的磁盤信息立轧，只需要通過某種方式得到對(duì)象的 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葛躏、長(zhǎng)度等，結(jié)合這些信息就可以算出對(duì)象存儲(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)，只支持追加寫嘁捷，因此只能用在單一場(chǎng)景造成。Tectonic 的客戶端和 GFS 差不多，也不支持 POSIX 標(biāo)準(zhǔn)雄嚣，只支持追加寫晒屎，但 Tectonic 采用了一種富客戶端的設(shè)計(jì)喘蟆，把很多功能都放在客戶端這一邊來實(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)開始向云端遷移榛了，這些對(duì)性能要求更高的場(chǎng)景給文件存儲(chǔ)提出了新的挑戰(zhàn)在讶。JuiceFS 誕生于這樣的時(shí)代背景，作為一款基于對(duì)象存儲(chǔ)的分布式文件系統(tǒng)忽冻，JuiceFS 希望能夠?yàn)楦嗖煌?guī)模的公司和更多樣化的場(chǎng)景提供可擴(kuò)展的文件存儲(chǔ)方案真朗。
關(guān)于作者
高昌健
Juicedata 技術(shù)專家，參與建設(shè) JuiceFS 開源社區(qū)的主力隊(duì)員
