1. 程式人生 > >Facebook兆級別圖片儲存及每秒百萬級別圖片查詢原理

Facebook兆級別圖片儲存及每秒百萬級別圖片查詢原理

前言

Facebook(後面簡稱fb)是世界最大的社交平臺,需要儲存的資料時刻都在劇增(佔比最大為圖片,每天儲存約20億張,大概是微信的三倍)。

那麼問題來了,fb是如何儲存兆級別的圖片?並且又是如何處理每秒百萬級別的圖片查詢?

本文以簡單易懂,圖文並茂的方式來解釋其中的原理,並不涉及空洞,難解的框架,也沒有大篇章的廢話鋪陳,只有痛點與反思;就如同fb的架構師所說:fb的儲存架構就像高速公路上換輪胎,沒有最完美的設計,我們最求的只是如何讓它變得更簡單。

短篇介紹

fb的圖片儲存系統叫做HayStack,目前已儲存超過120PB的資料,使用者每天會上傳20億張圖片。fb圖片搜尋峰值,需要提供每秒100-200萬張的圖片搜尋。這些資料還再不斷地增加。

稍微分析下使用者使用場景,圖片寫入一次,頻繁讀取,從不修改,很少刪除。傳統的檔案系統:每個圖片都會有一些元資料,在我們的需求中,這些資訊無用,且浪費儲存空間,更大的效能消耗是檔案的元資料需要從磁碟讀到記憶體中來定點陣圖片位置,在fb的量級上,元資料的吞吐量便是一個巨大的瓶頸。

高吞吐量,低延遲是HayStack所追求的,所以HayStack希望每個圖片讀取操作至多需要一個磁碟,並且減少每個圖片的必要元資料,並將它們儲存至記憶體中。為了做好容災,HayStack會將圖片複製多張並儲存至不通資料中心,以確保不反回404,error給客戶。

典型的設計方案

 

 

 

 

上圖為典型的設計方案:

1.使用者通過瀏覽器傳送圖片資訊請求至web server;2.web server 構造一個url,引導瀏覽器到對應位置下載圖片;3.通常這個url指向一個CDN,如果CDN有快取相關圖片的話,它會將圖片立刻返回給瀏覽器;4.否則,會解析url,並在Photo Storage中找到對應的圖片;5.6.返回給使用者。

NAS-NFS

在fb的服務中,只有CDN不足以解決全部需求,對於新圖片,熱門圖片CDN確實很高效。但是對於一些個人上傳的老圖片請求,CDN基本上會全部命中失敗,又沒有辦法將圖片全部快取起來。所以這裡,可以採用NAS-NFS來解決問題。

 

 

 

 

基本操作與上面相同,5.6.photo store server 解析url得出完整的卷和路徑資訊,在NFS上讀取資料,然後返回給CDN。

這種設計的瓶頸:NFS卷的每個目錄下儲存上千張圖片,導致讀取時產生了過多的磁碟操作。

HayStack

HayStack架構包含3個核心元件:HayStack Store,HayStack Directory和HayStack Cache。 Store是儲存系統,負責管理圖片的元資料。不同機器上的物理卷對應一個邏輯卷,HayStack將一個圖片儲存至一個邏輯卷時,那麼圖片便對應寫入所有物理卷。Directory 維護了邏輯到物理卷的對映以及相應的元資料,例如說,某張圖片儲存在哪個物理卷裡,某個物理卷的儲存空間等。Cache的功能,類似內部的CDN,它幫Store擋住熱門搜尋。

 

 

 

 

 

上圖描述了3個核心元件的相互作用。在HayStack架構中,瀏覽器的請求被引導至CDN中(或Cache上),Cache本質就是CDN,為了避免衝突,我們使用CDN來表示外部系統,使用Cache表示內部系統。

1.當用戶發出請求給web server,2.web server 使用Directory來構建圖片的url,3.4.5.6.7.8.9.10.url包含一段資訊,如下:

http(s)://CDN/Cache/machine_id/volume_ID_Photo

一目瞭然,url包含CDN地址資訊,Cache資訊,以及儲存圖片的物理卷ID,以及圖片資訊。

 

 

 

 

圖4,位使用者上傳圖片的流程,1.使用者傳送請求至web server;2.web server請求Directory一個可用的邏輯卷,物理卷,並將圖片資訊記錄下;3.將相關資訊傳送至web server;4.web server將圖片上傳至Store;5.返回成功資訊。

Directory

主要有4個功能:

1.它提供了邏輯捲到物理卷的對映,web伺服器上傳或讀取圖片時需要使用這個對映。

2.它在分配寫請求,讀請求到物理卷時,需保證負載均衡。

3.它決定一個圖片的請求,是傳送至CDN或Cache,這個決定可以動態調整是否依賴CDN。

4.它指定哪些卷是隻讀的。

當我們增加Store的時候,那些卷都是可寫的,可寫的機器會收到上傳資訊。當它們到達容量上限時,標記它們為只讀。

Cache

Cache的實現可以理解為一個分散式Hash Table,以圖片ID為key,定位快取的圖片資料。如果Cache未命中,那麼Cache則根據URL到指定的Store中,讀取圖片資料。

Store

很簡單,根據提供的一些元資料資訊,包括圖片ID,邏輯卷ID,物理卷ID,找到對應的圖片,未找到則返回錯誤資訊。

下面簡單描述一下物理卷與對映的結構,一個物理卷可以理解為一個大型檔案,包含一系列的needle,每個needle就是一張圖片。如下圖所示。

 

 

 

 

 

 

 

 

為了快速索引needle,Store需要為每個卷提供一個記憶體中的key-value對映。

HayStack檔案系統

HayStack可以理解成基於Unix檔案系統搭建的物件儲存架構。Store使用的檔案系統是XFS,XFS有兩個優點,首先,XFS中的臨近大型檔案的blockmap很小,可放入記憶體儲存。再者,XFS提供高效的檔案預分配,減少磁碟碎片問題。使用XFS,可以完全避免檢索檔案系統導致的磁碟操作。

文末也給大家,分享主要有C/C++,Linux,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒體,CDN,P2P,K8S,Docker,TCP/IP,協程,DPDK技術,面試技巧方面的資料技術討論。

感興趣的朋友可