對于檔案系統而言，其讀寫的效率對整體的系統性能有決定性的影響，本文我們將通過介紹 JuiceFS 的讀寫請求處理流程，讓大家對 JuiceFS 的特性有更進一步的了解，
寫入流程
JuiceFS 對大檔案會做多級拆分（參見 JuiceFS 如何存盤檔案），以提高讀寫效率，在處理寫請求時，JuiceFS 先將資料寫入 Client 的記憶體緩沖區，并在其中按 Chunk/Slice 的形式進行管理，Chunk 是根據檔案內 offset 按 64 MiB 大小拆分的連續邏輯單元，不同 Chunk 之間完全隔離，每個 Chunk 內會根據應用寫請求的實際情況進一步拆分成 Slices；當新的寫請求與已有的 Slice 連續或有重疊時，會直接在該 Slice 上進行更新，否則就創建新的 Slice，
Slice 是啟動資料持久化的邏輯單元，其在 flush 時會先將資料按照默認 4 MiB 大小拆分成一個或多個連續的 Blocks，并上傳到物件存盤，每個 Block 對應一個 Object；然后再更新一次元資料，寫入新的 Slice 資訊，顯然，在應用順序寫情況下，只需要一個不停增長的 Slice，最后僅 flush 一次即可；此時能最大化發揮出物件存盤的寫入性能，
以一次簡單的 JuiceFS 基準測驗為例，其第一階段是使用 1 MiB IO 順序寫 1 GiB 檔案，資料在各個組件中的形式如下圖所示：
注意：圖中的壓縮和加密默認未開啟，欲啟用相關功能需要在 format 檔案系統的時候添加
--compress value或--encrypt-rsa-key value選項，
這里再放一張測驗程序中用 stats 命令記錄的指標圖，可以更直觀地看到相關資訊：
上圖中第 1 階段：
- 物件存盤寫入的平均 IO 大小為
object.put / object.put_c = 4 MiB，等于 Block 的默認大小 - 元資料事務數與物件存盤寫入數比例大概為
meta.txn : object.put_c ~= 1 : 16，對應 Slice flush 需要的 1 次元資料修改和 16 次物件存盤上傳，同時也說明了每次 flush 寫入的資料量為 4 MiB * 16 = 64 MiB，即 Chunk 的默認大小 - FUSE 層的平均請求大小為約
fuse.write / fuse.ops ~= 128 KiB，與其默認的請求大小限制一致
相較于順序寫來說，大檔案內隨機寫的情況要復雜許多；每個 Chunk 內可能存在多個不連續的 Slice，使得一方面資料物件難以達到 4 MiB 大小，另一方面元資料需要多次更新，同時，當一個 Chunk 內已寫入的 Slices 過多時，會觸發 Compaction 來嘗試合并與清理這些 Slices，這又會進一步增大系統的負擔，因此，JuiceFS 在此類場景下會比順序寫有較明顯的性能下降，
小檔案的寫入通常是在檔案關閉時被上傳到物件存盤，對應 IO 大小一般就是檔案大小，從上面指標圖的第 3 階段（創建 128 KiB 小檔案）中也可以看到：
- 物件存盤 PUT 的大小就是 128 KiB
- 元資料事務數大致是 PUT 計數的兩倍，對應每個檔案的一次 Create 和一次 Write
值得一提的是，對于這種不足一個 Block 的物件，JuiceFS 在上傳的同時還會嘗試寫入到本地 Cache（由 --cache-dir 指定，可以是記憶體或硬碟），以期能提升后續可能的讀請求速度，從指標圖中也可以看到，創建小檔案時 blockcache 下有同等的寫入帶寬，而在讀取時（第 4 階段）大部分均在 Cache 命中，這使得小檔案的讀取速度看起來特別快，
由于寫請求寫入 Client 記憶體緩沖區即可回傳，因此通常來說 JuiceFS 的 Write 時延非常低（幾十微秒級別），真正上傳到物件存盤的動作由內部自動觸發（單個 Slice 過大，Slice 數量過多，緩沖時間過長等）或應用主動觸發（關閉檔案、呼叫 fsync 等），緩沖區中的資料只有在被持久化后才能釋放，因此當寫入并發比較大或者物件存盤性能不足時，有可能占滿緩沖區而導致寫阻塞，
具體而言，緩沖區的大小由掛載引數 --buffer-size 指定，默認為 300 MiB；其實時值可以在指標圖的 usage.buf 一列中看到，當使用量超過閾值時，JuiceFS Client 會主動為 Write 添加約 10ms 等待時間以級訓寫入速度；若已用量超過閾值兩倍，則會導致新的寫入暫停直至緩沖區得到釋放，因此，在觀察到 Write 時延上升以及 Buffer 長時間超過閾值時，通常需要嘗試設定更大的 --buffer-size，另外，通過增大 --max-uploads 引數（上傳到物件存盤的最大并發數，默認為 20）也有可能提升寫入到物件存盤的帶寬，從而加快緩沖區的釋放，
回寫（Writeback）模式
當對資料的一致性和可靠性要求并不高時，還可以在掛載時添加 --writeback 以進一步提升系統性能，回寫模式開啟后，Slice flush 僅需寫到本地 Staging 目錄（與 Cache 共享）即可回傳，資料由后臺執行緒異步上傳到物件存盤，請注意，JuiceFS 的回寫模式與通常理解的先寫記憶體不同，是需要將資料寫入本地 Cache 目錄的（具體的行為根據 Cache 目錄所在硬體和本地檔案系統而定），換個角度理解，此時本地目錄就是物件存盤的快取層，
回寫模式開啟后，還會默認跳過對上傳物件的大小檢查，激進地盡量將所有資料都保留在 Cache 目錄，這在一些會產生大量中間檔案的場景（如軟體編譯等）特別有用，
此外，JuiceFS v0.17 版本還新增了 --upload-delay 引數，用來延緩資料上傳到物件存盤的時間，以更激進地方式將其快取在本地，如果在等待的時間內資料被應用洗掉，則無需再上傳到物件存盤，既提升了性能也節省了成本，同時相較于本地硬碟而言，JuiceFS 提供了后端保障，在 Cache 目錄容量不足時依然會自動將資料上傳，確保在應用側不會因此而感知到錯誤，這個功能在應對 Spark shuffle 等有臨時存盤需求的場景時非常有效，
讀取流程
JuiceFS 在處理讀請求時，一般會按照 4 MiB Block 對齊的方式去物件存盤讀取，實作一定的預讀功能，同時，讀取到的資料會寫入本地 Cache 目錄，以備后用（如指標圖中的第 2 階段，blockcache 有很高的寫入帶寬），顯然，在順序讀時，這些提前獲取的資料都會被后續的請求訪問到，Cache 命中率非常高，因此也能充分發揮出物件存盤的讀取性能，此時資料在各個組件中的流動如下圖所示：
注意：讀取的物件到達 JuiceFS Client 后會先解密再解壓縮，與寫入時相反，當然，如果未啟用相關功能則對應流程會直接跳過，
做大檔案內隨機小 IO 讀取時，JuiceFS 的這種策略則效率不高，反而會因為讀放大和本地 Cache 的頻繁寫入與驅逐使得系統資源的實際利用率降低，不幸的是，此類場景下一般的快取策略很難有足夠高的收益，此時可考慮的一個方向是盡可能提升快取的整體容量，以期達到能幾乎完全快取所需資料的效果；另一個方向則可以直接將快取關閉（設定 --cache-size 0），并盡可能提高物件存盤的讀取性能，
小檔案的讀取則比較簡單，通常就是在一次請求里讀取完整個檔案，由于小檔案寫入時會直接被快取起來，因此類似 JuiceFS bench 這種寫入后不久就讀取的訪問模式基本都會在本地 Cache 目錄命中，性能非常可觀，
總結
以上就是本文所要簡單闡述的 JuiceFS 讀寫請求處理流程相關的內容，由于大檔案和小檔案的特性差異，JuiceFS 通過對不同大小的檔案執行不同的讀寫策略，從而大大的提升了整體性能和可用性，可以更好的滿足用戶對不同場景的需求，
推薦閱讀：如何在 Kubernetes 集群中玩轉 Fluid + JuiceFS
如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0?0?)
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/374373.html
標籤：架構設計