Facebook圖檔存儲系統Haystack——存小檔案，本質上是将多個小檔案合并為一個大檔案來降低io次數，meta data裡存偏移量轉自：http://yanyiwu.com/work/2015/01/04/Haystack.html

因為【傳統檔案系統的弊端】

因為【緩存無法解決長尾問題】

是以【多個圖檔資訊(Needle)存在同一個檔案(SuperBlock)中】

是以【顯著提高性能】

傳統的 POSIX 檔案系統不适合高性能的圖檔存儲， 主要原因是基于該檔案系統來存儲的話，是講每個圖檔存儲成某目錄下的一個檔案， 每次讀取檔案的時候需要有N次磁盤IO，當目錄下檔案數是K級别是， 讀取一次檔案需要超過10次的檔案IO，即使目錄下的檔案數是0.1K級别時， 也需要3次的檔案IO（1:讀取目錄中繼資料,2:讀取inode,3:讀取檔案内容）。

圖檔存儲的應用場景如圖：

在 PhotoStorage 之前還有一些 CDN 保駕護航， CDN 就是靠緩存吃飯的，對于那些熱門的圖檔都能被 CDN 很好的緩存下來， 是以需要通路的 PhotoStorage 一般都是非熱門圖檔， 是以在這樣的場景之下， 在 PhotoStorage 改進緩存顯然是無法解決問題的。 你懂的，緩存對于長尾問題基本上都是束手無策的。 因為如果緩存能解決的問題，就不叫長尾問題了。

每次讀取一個圖檔需要多次磁盤IO的原因是因為一個圖檔存成一個檔案， 檔案系統裡面每次讀取檔案需要先讀取檔案的元資訊等，導緻多次磁盤IO， 而當我們将多個圖檔資訊存在同一個檔案中， 當然這個檔案會很大， 然後在記憶體中存儲該圖檔存儲在檔案中的偏移位址和圖檔大小， 是以每次讀取圖檔的時候， 根據偏移位址直接讀取讀取， 大部分情況下能做到隻需要一次磁盤IO即可。 進而顯著提高性能。

基于這個思想，haystack 設計者繞過了 POSIX 檔案系統這塊，把 haystack 變成了一個 KV FS，即 NOFS。每個圖檔對應一個 FID，不再單獨存放檔案系統中，而是同一個實體卷 Volume 圖檔全部寫入一個檔案中，由 Volume Server 記憶體維護 FID : <Volume Machine, Offset, Size> 映射關系，Volume Server 記憶體中維護打開的檔案句柄，讀取圖檔時隻需一次 IO 順序讀操作。

haystack架構圖

架構比較簡單，分為三部份：Haystack Directory, Haystack Cache, Haystack Store

Directory: 即所謂的 Meta Server

1. 生成 FID，維護 logical volume 與 physical volume 映射關系，解決上傳時的負載均衡問題。 2. 新加入的 Store Server 要在這裡注冊。 3. 維護 logical volume 的 read-only 屬性，隻讀的 logical volume 不再接受 upload 請求。 4. 決定請求走 CDN 還是内部 Haystack Cache Server.

Cache: 所謂的内部 CDN

1. 對圖檔 FID 采用一緻性 hash 算法儲存。 2. 隻緩存使用者請求，而不是來自 CDN 的請求。 3. 隻緩存 write-enabled store 圖檔，由于上傳的時間序，相當于隻緩存最新生成的圖檔。比如說使用者剛上傳的圖檔，可能就會存到 Cache 中預熱。

Store: 最終落地存儲服務

1. 圖檔順序追加到一個大檔案中，記憶體中維護圖檔在檔案中的 Offset 和 Size 的索引資訊。 2. 為了解決重新開機快速加載問題，索引資訊會單獨儲存到一個 Index File 中。

本文轉自張昺華-sky部落格園部落格，原文連結：http://www.cnblogs.com/bonelee/p/6516500.html，如需轉載請自行聯系原作者