轉自：http://yanyiwu.com/work/2015/01/04/Haystack.html
一篇14頁的論文Facebook-Haystack， 看完之后我的印象里就四句話：
- 因為【傳統文件系統的弊端】
- 因為【緩存無法解決長尾問題】
- 所以【多個圖片信息(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即可。 從而顯著提高性能。
轉載請注明出處: Facebook圖片存儲系統Haystack
基於這個思想，haystack 設計者繞過了 POSIX 文件系統這塊，把 haystack 變成了一個 KV FS，即 NOFS。每個圖片對應一個 FID，不再單獨存放文件系統中，而是同一個物理卷 Volume 圖片全部寫入一個文件中，由 Volume Server 內存維護 FID : <Volume Machine, Offset, Size> 映射關系，Volume Server 內存中維護打開的文件句柄，讀取圖片時只需一次 IO 順序讀操作。
架構比較簡單，分為三部份：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 中。