臉書Haystack檔案系統是處理大流量的長尾請求的？

banq發表於2021-06-08

本文介紹了 Haystack，這是一種為 Facebook 的照片應用程式設計的物件儲存檔案系統。Haystack 旨在為透過在大型社交網路中共享照片而看到的長尾請求提供服務。關鍵的特點是在訪問後設資料時避免磁碟操作。與使用 NAS 裝置的傳統方法相比，Haystack 提供了一種容錯且簡單的照片儲存解決方案，其成本顯著降低，吞吐量更高。
開源SeaweedFS檔案系統實際上最初是基於Facebook設計的儲存系統，如 Haystack、f4 和新的 Tectonic 儲存系統。Haystack儲存系統的設計解決了最大社交網路平臺中真實世界的檔案系統問題，並提供相當簡單的解決方案且有效又易於來推理、實現和維護。
  

檔案系統和CDN問題
在傳統的基於 POSIX 的檔案系統中，一切都被建模為一個檔案，每個檔案都有其關聯的後設資料，例如許可權，這些後設資料基本上不用於此類系統，從而導致相當大的空間浪費（每個影像的幾個位元組乘以數十億和數十億的儲存影像）。
我們可以理解無用的後設資料會浪費空間，但磁碟空間並不是真正的問題。當從磁碟讀取影像時，這裡的真正問題就會浮出水面。當從基於 POSIX 的檔案系統中的磁碟讀取影像時，會發生以下情況：

  1. 進行一次（通常更多）磁碟操作將檔名轉換為inode 編號。一個索引節點是像該檔案，其中包含有關該檔案的資訊，例如，檔案型別，許可權，UID，GID等檔案的序列號
  2. 從磁碟獲取 inode 的一項磁碟操作。
  3. 從磁碟獲取檔案本身的最終磁碟操作。

我們可以很容易地看到，僅僅讀取檔案的後設資料就浪費了 2 個（或更多）磁碟操作。
CDN為頻繁訪問承擔了負載，它還減輕了儲存系統的負載，但是CDN 方法僅適用於最近請求的內容，但 facebook也有很多不那麼受歡迎的內容（舊圖片）產生大量流量，他們稱之為長尾。
邏輯上講，對長尾的請求將導致CDN中的快取未命中，並會影響儲存系統，從而導致高讀取流量。當快取更多熱門內容時，因為CDN大小限制，有點舊的資料也會很快從CDN過期失效，因此幾乎總是必須由儲存系統提供所有大流量服務。
 

Haystack
舊的NFS系統中的主要吞吐量瓶頸是磁碟操作扇出（每次讀取檔案時再執行4次磁碟操作），這主要浪費在獲取檔案後設資料上。我們一致認為，在主記憶體中載入所有後設資料將消除這些磁碟操作，但由於其大小和儲存的大量檔案，這是不切實際的。因此，其主要思想是最小化每個檔案的後設資料，以便可以有效地將其載入到主記憶體中。
Haystack使用了一種直接的方法：它將多張照片儲存在一個檔案中，因此可以維護非常大的檔案。請注意，後設資料是每個檔案的開銷，因此與許多小檔案相比，使用非常大的檔案將減少後設資料的總體大小，從而實現能夠將其全部載入到主記憶體中的目標。
需要注意的是 Haystack 有兩種不同型別的後設資料：

  1. 應用程式後設資料：描述構建瀏覽器可用於檢索照片的 URL 所需的資訊。
  2. 檔案系統後設資料：標識主機檢索駐留在該主機磁碟上的照片所需的資料。

Haystack 架構由 3 個核心元件組成：Haystack Store、Haystack Directory和Haystack Cache。
簡要介紹一下每個元件：
  • Haystack Store負責封裝影像的持久儲存檔案系統，並且是唯一處理檔案系統後設資料的元件。Store 的容量是按物理卷組織的，例如，10 TB 的容量被組織成 100 個物理卷，每個物理卷提供 100 GB 的儲存空間。物理卷被分組到邏輯卷中，因此當要儲存映像時，它會被複制到同一邏輯卷中的所有物理卷。這種冗餘可以減少由於硬碟驅動器故障、磁碟控制器錯誤等造成的資料丟失。
  • Haystack Directory維護邏輯卷與其對應的物理卷以及其他應用程式後設資料之間的對映，例如儲存每個映像的邏輯卷和具有可用儲存空間的邏輯卷。
  • Haystack Cache用作內部 CDN，保護 Haystack Store 免受對最流行影像的請求的影響，並在上游 CDN 節點出現故障並需要重新獲取內容時提供隔離（通常稱為快取踩踏）。

臉書Haystack檔案系統是處理大流量的長尾請求的？

上圖顯示了所有 3 個元件如何互動以服務流量（熱流量和長尾流量），如下所示：

  1. 瀏覽器向後端 Web 伺服器傳送 HTTP 請求以獲取影像。
  2. 後端伺服器與 Haystack 目錄通訊以獲取請求影像的 URL。
  3. Haystack 目錄查詢其應用程式後設資料並獲取所請求影像的 URL 並將其傳送回後端伺服器。請記住，目錄是儲存每個檔案的位置。
  4. 後端伺服器將影像 URL 返回給瀏覽器。
  5. 瀏覽器要麼從 CDN 請求影像，要麼根據返回 URL 中提供的資訊直接請求 Haystack 快取（我們將在稍後討論）。
  6. CDN 在其快取中查詢影像並在快取命中的情況下將其提供回來，但在快取未命中的情況下，它會回退到 Haystack 快取。
  7. Haystack 快取在其自己快取中查詢影像，並在快取命中的情況下將其提供回 CDN，但在快取未命中的情況下，它會回退到 Haystack Store。
  8. 獲取的影像從 Haystack Store 返回到 Haystack Cache，在那裡它被快取（或不基於一些稍後討論的邏輯）。
  9. Haystack Cache 將影像返回給 CDN。
  10. CDN 快取影像並將其返回給瀏覽器。

現在我們來看看Haystack Directory生成的URL，一般長這樣：

https://<CDN>/<Cache>/<Machine id>/<Logical volume, photo>


URL的第一部分指定從哪個CDN請求照片。CDN只能使用URL的最後一部分（邏輯卷和照片id）在內部查詢照片。如果CDN找不到照片，則會從URL中刪除CDN地址並與快取聯絡。快取會執行類似的查詢來查詢照片，如果找不到，則會從URL中刪除快取地址，並從指定的儲存計算機請求照片。另一方面，直接到快取的請求具有類似的工作流，只是URL缺少CDN特定的資訊。
 

評估
讓我們看看 Haystack 是否真的實現了：

  1. 高吞吐量和低延遲：Haystack 透過每次讀取最多需要一個磁碟操作來實現高吞吐量和低延遲，這可以透過最小化後設資料大小並將其載入到主記憶體中來實現。基於論文中完成的基準測試，它還能夠實現 4X 每秒每 TB 可用儲存的標準化讀取率更高。
  2. 容錯：Haystack 透過將每個影像複製到 3 個地理位置不同的位置來實現容錯。這種複製保證了當一臺主機當機時，它可以在修復期間被另一臺主機替換，並保持零當機時間。
  3. 成本效益：Haystack 在我們提到的每個可用 TB 成本的兩個維度上都實現了成本效益～28% 少和流程 ～4X 每秒讀取數比 NAS 裝置上的同等 TB 多。
  4. 簡單性：Haystack 透過採用大多數直接的方法來解決問題來實現簡單性，這使得開發速度更快，更易於操作和維護。


詳細點選標題

相關文章