分享照片是 Facebook 最核心的功能之一。截至 2010 年，用戶已上傳超過 15 億張照片，Facebook 為每張照片生成 4 種尺寸（原圖、大、中、縮圖），總計 60 億張影像，總容量超過 1.5 PB。每週新增 2,200 萬張（約 25 TB），尖峰流量達 55 萬張/秒。面對這樣的規模，傳統 NFS 檔案系統已無法勝任，Facebook 設計了專用的 Haystack 物件儲存系統。

舊架構：NFS 檔案系統的瓶頸

三層架構

1. 上傳層：接收上傳，寫入 NFS。
2. 照片服務層：處理 HTTP 請求，從 NFS 讀取回傳。
3. NFS 儲存層：商用 NAS 設備。

核心問題：龐大的中繼資料

• 每張照片為一個獨立檔案 → 數十億個 inode、目錄項目。
• 中繼資料量遠超 NFS 快取容量 → 每次讀寫觸發多次磁碟 I/O（查 inode、查間接區塊）。
• 結果：I/O 多數花在檔案系統中繼資料，而非照片資料本身。

權宜之計

• Cachr：快取小尺寸頭貼照片。
• NFS 檔案控制代碼快取：減少中繼資料查找開銷。
• 高度依賴 CDN 卸載讀取流量。

新架構：Haystack 物件儲存

核心思想：將「輸出層」與「儲存層」合併為單一 HTTP 照片伺服器，照片以「物件」形式存放於 Haystack，繞過檔案系統中繼資料，I/O 僅針對照片資料本身。

硬體配置（單一儲存刀片）

• 2U 機箱，雙 4 核心 CPU
• 16~32 GB 記憶體
• 硬體 RAID-6 + 256~512 MB NVRAM 寫回快取
• 12+ 顆 1 TB SATA 硬碟 → 約 10 TB 可用容量
• RAID-6 兼顧成本、效能、冗余；NVRAM 專用於寫入加速（讀取多為隨機，難以快取）。

檔案系統：XFS + 大區塊預分配

• 單一 10 TB XFS 檔案系統承載 Haystack 檔案。
• XFS 高效的預分配避免大檔案碎片化，確保連續區塊映射緊湊，減少間接區塊層級。

Haystack 邏輯結構：兩個檔案

1. 儲存檔：循序追加的資料檔，包含超級區塊（8 KB）+ 多個「針」。
2. 索引檔：每個針對應一筆索引記錄，載入記憶體供 O(1) 查找。

針 的結構

• 以 (Haystack ID, Key, Alternate Key, Cookie) 四元組唯一標識。
• Header：版本、旗標、大小、Key、Alternate Key、Cookie、建立時間。
• Data：照片二進位資料。
• Footer：CRC32 校驗碼。
• 允許重複 Key（新版本追加在尾部，Offset 最大者為最新）。

索引檔佈局

• 每筆記錄：Key, Alternate Key, Cookie, Offset, Size, Flags。
• 順序與儲存檔一致，可從儲存檔重建（故索引檔非關鍵，可異步寫入）。
• 索引大小約為儲存檔的 1%，極易完整置於記憶體。

核心操作流程

寫入（同步追加儲存檔，異步更新索引）

1. 將針追加寫入儲存檔（同步，確保持久化）。
2. 累積一定數量後，批次寫入索引檔（異步，提升效能）。
3. 定期將索引檔同步至磁碟；崩潰恢復時掃描儲存檔重建索引。

讀取（單次 I/O 直達資料）

1. HTTP 伺服器從記憶體索引查找 Offset, Size。
2. 單次 pread 讀取完整針（Header + Data + Footer）。
3. 驗證 Key、Alternate Key、Cookie、CRC32、刪除旗標；通過則回傳 Data。

刪除（邏輯標記，不回收空間）

• 在儲存檔的針 Header 設定「已刪除」旗標。
• 記憶體索引將 Offset 設為 0。
• 不做空間回收，保持儲存檔緊湊、追加寫入特性。

整理

• 線上操作：建立新 Haystack，複製有效針（跳過刪除/重複），原子替換檔案與記憶體索引。

照片服務器：記憶體索引快取

• 啟動時將所有 Haystack 索引載入記憶體（Google sparsehash，每項僅 2 bit 開銷）。
• 每張照片索引項：Haystack ID, Key, Alternate Key, Cookie, Offset, Size, Flags。
• 上傳流程：分配 64-bit 照片 ID → 生成 4 尺寸 → 同 Key 不同 Alternate Key（尺寸標識）+ 同 Cookie → 寫入 Haystack → 更新記憶體索引。

HTTP 伺服器

• 基於 libevent 的 evhttp，多執行緒模型。
• 輕量、高併發、無框架開銷。

架構優勢總結

維度	NFS 架構	Haystack 架構
單張照片 I/O	多次（中繼資料 + 資料）	單次（直接讀資料）
中繼資料規模	數十億 inode，超出快取	記憶體索引 ~1% 體積，全在 RAM
擴展性	受限於 NAS 控制器	無狀態 HTTP 節點水平擴展
故障域	單一 NAS 故障影響大面	單一刀片故障僅影響 10 TB
成本	商用 NAS 昂貴	商用硬體 + 開源軟體，極低成本/TB

啟示與後續發展

Haystack 展示了針對特定工作負載（海量小物件、高讀低寫、不可變）設計專用儲存系統的威力。其核心思想——Log-Structured Merge (LSM) 風格的追加寫入、記憶體索引、邏輯刪除、定期整理——後來被廣泛應用於 RocksDB、LevelDB、Cassandra、HBase 等現代儲存引擎。Facebook 後續更推出 f4（暖儲存） 針對低頻照片進一步降低成本，但 Haystack 仍是熱照片儲存的核心基石。