【高手問答彙總】聊聊分散式檔案系統與 JuiceFS

 檔案系統是計算機中一個非常重要的元件，為儲存裝置提供一致的訪問和管理方式。在不同的作業系統中，檔案系統會有一些差別，但也有一些共性幾十年都沒怎麼變化：

1. 檔案以樹形目錄進行組織；
2. 資料是以檔案的形式存在，提供 Open、Read、Write、Seek、Close 等API 進行訪問；
3. 提供原子的重新命名（Rename）操作改變檔案或者目錄的位置。

檔案系統提供的訪問和管理方法支撐了絕大部分的計算機應用，Unix 的“萬物皆檔案”的理念更是凸顯了它的重要地位。JuiceFS 是一款開源分散式檔案系統，創新的將物件儲存作為底層儲存介質，實現了儲存空間的無限擴充套件。任何存入 JuiceFS 的檔案都會按照特定規則被拆分成固定大小的資料塊儲存在物件儲存，資料塊的元資料則儲存在 Redis、MySQL 等資料庫中。

OSCHINA 請來了 Juicedata 合夥人蘇銳 @蘇銳 和大家一起探討關於分散式檔案系統相關的問題。

嘉賓簡介

蘇銳，Juicedata 合夥人，作為1號成員參與建立分散式檔案系統 JuiceFS，先通過全球公有云上的 SaaS 產品獲得國內外幾十家商業客戶，之後於 2021 年 1 月 JuiceFS 開源。

---

問：JuiceFS 是依賴 redis、mysql 什麼版本呢？如何考慮系統安全問題呢？

答：Redis 可以參考最佳實踐，各種引擎用流行的版本都能支援，JuiceFS 會盡量相容更多的引擎和版本。

問：JuiceFS 的物件儲存相對傳統的塊儲存分散式檔案系統有啥優點？JuiceFS 的儲存現在是針對什麼業務場景使用的？

答：JuiceFS 是一個 object-based 的分散式檔案系統，相比 block-based 有更好的彈性。Object Storage 可以認為是完全彈性的，但是 Block Storage 大多做不到。目前 JuiceFS 主要用在 大資料、AI、DevOps 和各種需要 NAS 的應用場景，在 juicefs.com 上可以看到很多案例和客戶實踐。

問：​​如果檔案被拆分成固定大小的資料塊，那這些資料塊是怎麼保證順序的，以及資料庫塊的大小是固定的嗎？會不會出現大量的記憶體碎片？讀取的時候是不是要佔用大量記憶體進行合併資料庫 ？

答：比如想讀 1GB 的檔案，在儲存中是 sequential read。如果全部讀出來返回給請求端，更佔記憶體，呼叫端的等待時間更長。都是 4K/64K/256K/1M 等容量去順序讀，以一個 streaming 的方式持續返回給呼叫端。所以 JuiceFS 把檔案分成 block 儲存不會影響效能。相反，還能提升效能。因為更容易通過併發方式同時讀很多的 block 返回給呼叫端，當然獲得高吞吐的同時，需要用一點記憶體資源來換。檔案被分成很多 data block 存在物件儲存中，每個 block key 會存在 meta engine 裡（直接存太佔空間了，設計上 16 個 block 為一個 chunk，儲存 chunkid + offset）。block size 預設設為 4MiB 是最大值，實際會有小於該值的 block。碎片合併有的。讀取的時候不用擔心，各種儲存系統在讀的時候也都是按某個大小的 page/block 去讀。

問：考慮到存取速度、修復難度以及遷移，對於底層檔案系統的選擇有什麼推薦的嗎？

答：存取速度容易判斷，結合你的業務場景來測試評估就行了。我想說的是在分散式儲存中，只用一些 Benchmark Tool 來看跑分和實際業務場景中的表現是有不同的，一定用業務場景來測試。 遷移方面，通用流行的訪問協議都不難，比如 JuiceFS 完全相容 POSIX、HDFS、S3，還提供 juicesync 這個資料遷移工具，相容幾十種物件儲存的 API。要考慮的是資料遷移中，業務的影響。

問：JuiceFS 的跨節點、機架、機房、區域的副本放置策略，可用性程度，能不能簡單講講：一致性協議的實現以及涉及到元資料管理，主叢切換的及時性和正確性，最後就是各種突發情況下主從同步的策略，全面高效的負載均衡(空間/吞吐/副本)。

答：JuiceFS 社群版使用流行的資料庫引擎，包括 Redis、MySQL、PostgreSQL、TiKV 這些，每一個都有很多運維的實踐經驗。部署和運維的方案都用這些資料庫引擎社群推薦的，必要的地方 JuiceFS 會提供一些最佳實踐，比如使用 Redis 做元資料引擎。

問：JuiceFS 是否提供開放 Key-Value Storage 的 API 介面，以及有哪些支援的程式設計語言？另外，對於有大量小檔案寫入的效率如何？

答：可以用 S3 API 讀寫 JuiceFS 資料，參考文件，如果以 POSIX 方式訪問，各種程式語言都原生支援了。程式語言的 SDK 目前有 Java SDK（是相容 HDFS API 的）。

問：對於大檔案的拆分效能是如何？

答：JuiceFS 的優勢所在，參照文件。

問：1.JuiceFS和 NAS  NFS 儲存有啥區別？JuiceFS 優勢在哪裡？2.JuiceFS 使用了什麼設計模式？

答：1. 相比 NAS，JuiceFS 為雲環境設計；彈性容量；更豐富的訪問方式，包括 POSIX、HDFS、S3、K8s CSI；在 大資料、AI、DevOps 和眾多需要 NAS 的場景上都適用，更高性價比 2. 參考架構設計採用元資料與資料分離的設計方案。

問：同 Ceph 是一類產品嗎？如果是優勢在哪裡？

答：和 CephFS 是一類產品，詳情可以參考文件。

問：看了一篇利用 JuiceFS 實現 mysql 資料備份效能提升 10 倍的文章 裡面用到的 JuiceFS 自帶的效能分析工具真的不錯，希望老師能分享下它的設計和架構。

答：可以參考文件，然後再去看對應的程式碼實現。

問：JuiceFS 主要應用場景是什麼呢

答：JuiceFS 可以應用於大資料、AI、容器平臺、DevOps 等場景，具體可以參考文件，也可以關注公眾號：Juicedata。

問：在官方文件中看到了 JuiceFS 和 Ceph、Alluxio 等產品的對比，但是感覺實際中的競爭對手可能是 MinIO 或者 OZone，請問是否做過與這2個產品的對比呢？最近在做物件儲存的技術調研，主要是儲存照片、音影片和文字檔案等，麻煩給一些意見，感謝！

答：MinIO 和 OZone 都是物件儲存。JuiceFS 是檔案系統，可以使用他倆做後端的持久層服務。如果您的需求是儲存和訪問，沒有計算、分析、訓練等場景，應該直接用物件儲存更適合。

問：請問下 JuiceFS  對於海量的小檔案儲存適合嗎？效能如何？客戶有歷史檔案，包括上億的資料夾和檔案。

答：使用 Redis 做元資料引擎推薦儲存 2億以內檔案，使用 TiKV 適合更大規模。效能要看場景，對於訓練等讀為主的場景有 cache 機制加速，效能不錯。

如果 1 億檔案 Redis，MySQL，TiKV 都沒有問題。要看你對哪個系統更熟悉，更有維護經驗。效能方面要看業務場景、訪問方式來做判斷。

問：請問在底層實現上是如何保證分散式檔案系統的檔案完整性的？

答：簡單說幾點：1. 先寫資料再寫元資料，保證元資料寫成功則資料完整；2. 元資料這邊靠引擎的事務性來保證完整；3. 寫進去之後 資料和元資料本身的可靠性分別依賴物件儲存和元資料引擎來保證；4. 會使用物件儲存提供的 checksum 能力。

問：這個是類似 Fastdfs 做檔案儲存的嗎，有什麼區別現在企業中哪個好用？

答：JuiceFS 面向雲環境設計，在雲環境中可以很容易用起來，也天然的做到彈性伸縮。在訪問時支援 POSIX、HDFS、S3，在上面做應用開發更方便，尤其是組織各種 Pipeline。

問：如果資料庫壞了，恢復了比如說一天前的備份，檔案資料也能確保恢復到一天前的狀態，並能持續工作下去嗎？

答：可以部分恢復，各種資料庫也都有更細粒度的容災方案，比如 Redis AOF、MySQL Binlog，可以最大限度減少資料丟失風險。另一方面，生產環境上也會用主備策略。資料刪除後，無論是元資料還是物件儲存中的資料都會被刪除。如果元資料恢復到之前一天的狀態，資料不能被恢復，也是讀不出來的。

問：有沒有可能，在物件儲存中也存一個類似 binlog 的概念的日誌，當資料庫資料丟失又未備份時，可以通過這個類似 binlog 的結構，還原整個資料庫？

答：新版上增加了自動備份元資料到物件儲存的功能，算是多一個備份。

問：我認為，分散式檔案系統，依賴於關係型資料庫，是設計思路錯誤。正確的應該是反過來，關係型資料庫，依賴於分散式檔案系統。這樣，單個數據庫中，對應的後臺硬碟空間是無限的。無論應用系統有多少容量的資料，關係型資料庫都可以在不分庫、不分表的情況下，通過增加新磁碟、調整分散式檔案系統配置引數，來解決問題。不知道蘇老師怎麼看？

答：理解您的說法，我也部分認可。JuiceFS 的架構設計在 High level 上與 Google File System 的那篇論文一直，採用元資料與資料分離管理的方式，也有很多其他的分散式檔案系統用了這個思路。不同的地方時，在 Low level design 中，目前看到的大部分 DFS 面向裸磁碟設計。

但是放在雲時代，我們重新抽象的去看這個問題，再結合我們自己十餘年使用 DFS 的業務經驗。DFS 承載了非常豐富的 Workload，對於規模、效能、永續性、可用性、成本等不同維度的要求是不一樣的。我們嘗試回答一個問題：如何用一個產品更好、更靈活的滿足更多、更豐富的業務場景？

然後，在 JuiceFS 的架構設計上，選擇用物件儲存做資料持久層（類似 chunk server，data node），因為物件儲存提供了成熟的 scalebility、availibility、high throughput、low cost 三方面的優勢，這正是資料持久層需要的核心能力。

元資料引擎做了外掛式設計，Redis、MySQL、TiKV、FoundationDB 等有各自的優勢，能滿足不同的業務場景需求。選擇這些成熟、流行的系統，另一個好處是在開發者中已經積累了大量的使用和運維經驗，不用增加學習負擔。這是 JuiceFS 設計社群產品的理念，友好的使用體驗，低學習門檻，合適但無需極致（我們另有極致版的設計）。

---

高手問答欄目檢視：主題 高手問答 - OSCHINA - 中文開源技術交流社群