Facebook圖片存儲架構技術全解析
原創【51CTO獨家特稿】照片應用程序是Facebook最流行的功能。直至目前為止，Facebook的用戶已經上傳了超過150萬幅照片，這使得Facebook成為最大的照片共享網站。對于每一個上傳的照片， Facebook生成并保存成4種不同大小的圖像，即總共有60億的圖片占1.5PB的存儲容量。目前的增長速度是每星期220萬個新照片，即每周消耗25TB的額外存儲空間。在高峰期，平均每秒會上傳550,000幅圖像。這些數字給Facebook的照片存儲基礎架構帶來了嚴重的挑戰。
NFS照片基礎架構
舊的照片基礎架構包含幾個層次：
◆上傳層接收用戶上傳的照片，測量原始圖像的大小并將其保存到NFS存儲層。
◆照片服務層接收HTTP照片請求，并向用戶提供保存于NFS存儲層的照片。
◆NFS存儲層建立于商業存儲設備之上。
由于每個圖像存儲在自己的文件內，所以根據命名空間目錄和文件inode（內節點），在存儲層產生了大量的元數據。這些元數據量遠遠超過了NFS存儲層的緩存能力，導致了上傳和讀取每張照片時成倍的I/O操作。整個照片服務的基礎架構由于NFS存儲層的大量元數據負荷而成為了一個瓶頸，這就是Facebook嚴重依賴CDNs來提供照片服務的原因之一。以下兩個附加的優化部署，用來在一定程度上減輕這個問題：
Cachr ：一個緩存服務層，用來緩存Facebook中較小的“個人資料”圖像。
NFS文件句柄緩存——部署在照片服務層，消除了一些NFS存儲級元數據負荷
Haystack照片基礎架構
新的照片基礎架構將照片服務層和存儲層合并為一個物理層。它實現了一個基于HTTP的照片服務器，把照片存儲在名為Haystack的通用對象中。對于新層次的主要要求是消除任何照片讀取操作的不必要的元數據開銷，使每個讀取I/O操作只是讀取實際照片數據（而不是文件系統元數據）。Haystack可劃分為以下一些功能層-
◆HTTP服務器
◆照片存儲
◆Haystack對象存儲
◆文件系統
◆存儲設備
以下各節中，我們會自底向上密切關注每一個功能層。
存儲設備
Haystack部署于日常存儲片之上。一個2U存儲片的典型硬件配置的是-
◆2 x 4核CPUs
◆16GB – 32GB內存
◆具有256MB – 512MB NVRAM緩存的硬件RAID控制器
◆12+ 1TB SATA驅動器
每個存儲片提供大約10TB的可用空間，配置為一個RAID-6分區，由硬件RAID控制器進行管理。RAID 6提供了足夠的冗余性和出色的讀取性能，可以降低存儲成本。RAID控制器NVRAM回寫高速緩存可以部分緩解低劣的寫性能。由于讀取大多是隨機的，所以NVRAM緩存完全保留給寫操作。磁盤高速緩存被禁用，以保證在系統崩潰或電源斷電時數據的一致性。#p#
文件系統
Haystack對象存儲實現于一個文件之上，該文件存儲在一個單一文件系統上，該文件系統建立于10TB volume（卷）大小的空間之上。
照片讀取請求導致read()系統調用請求讀取文件中不同偏移量的信息，但為了執行讀取操作，文件系統必須首先在實際物理卷上找到數據。在文件系統中，每個文件的是由一個名為inode的結構所描述，該結構包含一個塊映射，可以把邏輯文件偏移量映射到物理卷中的物理塊偏離量。對于大文件，根據所使用的文件系統類型的不同，塊映射可能會相當龐大。
基于塊的文件系統為每個邏輯塊維護其映射信息，對于大文件，這些映射信息將不會像通常那樣存入緩存的inode，而是儲存在間接地址塊，讀取文件數據時需要進行轉換。間接轉化可能存在好幾個層次，因此，根據間接地址塊是否被緩存，單一的讀取可能會導致若干個I/O操作。
基于范圍的文件系統只為連續的塊（區域）維護映射信息。對于一個連續大文件的塊映射只由一個區域組成，此區域的大小正好可以裝入inode之中。但是，如果該文件是嚴重地分散和不連續的，其區塊在卷中不連續，那么其塊映射可以隨之增長。有了基于范圍的文件系統，就可以通過積極分配一大塊空間來減少碎片。
目前，所選擇的文件系統是的XFS，基于范圍的文件系統提供有效文件預分配。
Haystack對象存儲
Haystack是一個簡單日志結構（只追加）的對象存儲，包含描述存儲對象的指針。一個Haystack包括兩個文件——實際的包含指針的Haystack存儲文件，以及一個索引文件。下圖顯示了Haystack存儲文件的結構布局：
第一個8KB的Haystack存儲由超級塊所占用。緊接著超級塊的是指針，每個指針由頁眉、數據、和頁腳組成。
一個指針是由其﹤Offset（偏移量）, Key, Alternate Key(替換鍵),Cookie﹥元組唯一確定，其中偏移量是指在Haystack存儲中的指針偏移量。Haystack對于關鍵字的值沒有任何限制，有的指針可以有多個關鍵字。下圖顯示的是索引文件的結構布局—
在Haystack存儲文件中，每個指針有一個相應的索引紀錄，而且指針索引紀錄的順序必須與Haystack存儲文件中相關的指針順序相匹配。索引文件提供查找Haystack存儲文件中某一特定指針所需的最小元數據。為了快速查找，把索引記錄載入并組織到一個數據結構中，這是Haystack應用程序（在我們的情況下是照片存儲）的職責。索引文件不是至關重要的，因為它可以根據所需從Haystack存儲文件中重建。索引的主要目的是可以快速加載指針元數據到內存中，而無須遍歷龐大的Haystack存儲文件，這是因為索引的大小通常還不到存儲文件的1％。
Haystack寫操作
Haystack寫操作同步添加新的指針到Haystack存儲文件中。當指針成功添加到龐大的Haystack存儲文件中之后，相應的索引記錄也被寫入索引文件。由于索引文件不是至關重要的，為了達到更快的性能，該索引記錄是異步寫。
索引文件還會定期被刷新到下面的存儲設備，以便限制由硬件故障所引起的恢復操作的程度。在系統崩潰或突然斷電的情況下，Haystack恢復程序丟棄所有存儲中的不完整的指針，同時截斷Haystack存儲文件直到最后一個有效的指針，然后，在Haystack存儲文件最后為所有跟蹤的孤立指針寫入丟失的索引記錄。
Haystack不允許覆蓋已存在的指針偏移量，因此，如果某個指針的數據需要修改，其修改后的新版本必須使用相同的﹤Key, Alternate Key, Cookie﹥元組。然后應用程序就可以認為，在那些有著多個關鍵字的指針中，具有最大偏移量的指針就是最新添加的指針。
Haystack讀操作
傳遞給Haystack讀操作的參數包括指針偏移量、關鍵字、替換鍵、Cookie和數據大小。然后Haystack添加頁眉和頁腳的大小到數據大小中，并從文件中讀取整個指針。只有當關鍵字、替換鍵和Cookie符合參數類型，所傳遞的數據通過校驗，并且指針沒有被之前的操作刪除時，讀操作才能成功（見下文）。
Haystack刪除操作
刪除操作很簡單——通過設置指針的標記域中的一個“deleted（已刪除）”標記位，標記Haystack存儲中的指針為已刪除。然而，相關的索引記錄并不進行任何方式的修改，因此一個應用程序可能會結束于引用某個已刪除的指針。對于這樣的指針的讀操作會注意到“deleted”標記，然后終止操作，提示操作錯誤，給出錯誤信息。已刪除的指針的空間不會以任何方式回收。回收已刪除指針的空間的唯一方法是壓縮c（見下文） 。
照片存儲服務器
照片存儲服務器負責接收HTTP請求，并轉化成相應的Haystack存儲操作。為了盡量減少讀取照片所需的I/ O操作次數，服務器在內存中保存一個Haystack存儲文件中所有照片偏移量的索引。啟動時，服務器讀取Haystack索引文件并生成一個內存中的索引。由于每個節點數以億計的照片（并且該數字只會隨著更大容量的驅動器而增加），我們必須確保該索引能夠裝入可用的內存中。這是通過在內存中保留最少數量的元數據來實現，只保留查找照片所需的信息。
當用戶上傳一個照片，該照片就被分配一個唯一的64位編號。然后將照片轉化為4個不同大小的圖片。每個圖片具有相同的隨機Cookie和64位關鍵字，合理的圖像大小（大，中，小，縮略圖）是儲存在替換鍵中。然后上傳服務器調用照片存儲服務器，把所有4個圖像存儲在Haystack中。
內存中的索引為每張照片保存以下信息：
Haystack使用開源Google稀疏散列數據結構來減小內存中的索引，因為使用它，每條記錄只占2位。
照片存儲寫/修改操作
寫操作寫入照片到Haystack，并更新內存索引。如果該索引中已經包含了具有相同關鍵字的記錄，那么這就是一個修改現有照片的操作，那么只修改索引記錄偏移量，以反映新圖像在Haystack存儲文件中的位置。照片存儲總是假設存在重復的照片（具有相同關鍵字的照片），只有存儲在最大偏移量位置的照片是有效的。
照片存儲讀操作
傳遞到讀操作的參數包括Haystack id 和照片關鍵字、大小和COOKIE 。服務器根據照片關鍵字，執行一個在內存索引上的查找操作，然后得到含有所需照片的指針偏移量。如果發現調用的是Haystack讀操作來讀取照片，那么如上所述，Haystack刪除操作并不更新Haystack索引文件記錄。因此，一個新的內存索引可能會包含之前刪除的照片的舊記錄。讀取之前刪除的照片將會導致操作失敗，并且內存中的索引會自動更新，設置已經刪除圖像的偏移量為0。
照片存儲刪除操作
在調用Haystack刪除操作之后，內存中的索引被更新，設置特定圖像的偏移量為0來表示該圖像已經被刪除。
壓縮
壓縮是一個聯機操作，可以回收已被刪除的指針和重復指針（具有相同關鍵字的指針）所占用的空間。它通過復制指針創建一個新的Haystack，跳過所有重復和已刪除的指針。每次這樣做，就會交換文件和內存中文件的結構。
HTTP服務器
我們使用的HTTP框架是由開源lib event圖書館所提供的簡單的evhttp服務器。我們使用多線程，同一時間內，每個線程能夠處理一個HTTP請求。因為我們的工作量最主要是由I/O操作產生，因此HTTP服務器的性能并不是至關重要的。
【編輯推薦】
