當前位置:首頁 » 存儲配置 » 圖片存儲分布式

圖片存儲分布式

發布時間: 2024-12-19 11:59:33

㈠ 淺析 Haystack 圖片存儲系統

Facebook在2010年的時候發表過一篇在分布式存儲系統領域很有名的一篇文章《Finding a needle in Haystack》來描述他們的圖片存儲系統,Haystack 存儲了超過2600億張圖片,大約佔了20TB的數據,用戶每周都會上傳10億張圖片,高峰時期的並發量在100萬以上(這是2010年的數據,現在很有可能上了一個數量級)。

在這個數量級之下,需要考慮的問題不僅僅是高吞吐,低延時,保證數據的一致性,還要考慮如何能節省流量,容易擴展,容錯等等。下面我們就來看下Haystack是怎樣滿足這些分布式系統的要素的。

圖片存儲系統的最大特點是數據只寫一次,讀取頻繁,不會修改,很少刪除。Facebook 一開始的存儲系統是基於NFS的NAS(Network Attached Storage), 但這種基於 POSIX 的文件系統無法支撐如此大的負載。其中主要的問題在於在圖片定址的過程中會產生過多的磁碟操作。

我們知道從傳統文件系統裡面讀取一個文件需要至少三次磁碟操作,第一次從硬碟中讀取目錄的 metadata 到內存中,然後讀取inode到內存,最後才從磁碟中讀取文件內容。

再者這些metadata裡麵包含了大量比如許可權控制這些對於圖片存儲系統來說無用的信息,也浪費了大量的磁碟空間。當像圖片這樣的靜態資源服務出現瓶頸的時候,自然就會想到使用 CDN (Content Delivery Networks) 系統。在傳統的設計中,一個圖片的 HTTP 請求發送後, 如果 CDN 有這個資源的緩存,就會立馬返回,反之 ,CDN 會將根據請求的 URL 從存儲系統裡面讀取圖片,更新緩存,然後再返回。在這樣的設計中,CDN 確實可以很有效地處理熱點圖片的請求。

但像 Facebook 這樣的社交網路中,有大量的請求是針對那些非熱點或者老內容的,用戶在請求那些長尾 (long tail) 內容時將沒有優化。當然,有些同學會說,那我可以將所有的圖片都緩存到 CDN,那確實會解決這個問題,但將會極大地增加資源的開銷。

為了減少那些直接 hit 到存儲系統的請求的磁碟操作,他們想到在第一次讀取文件的時候把filename到 file handle 的映射緩存到內存,在下一次讀取文件的時候,會調用自定義的open_by_filehandle來減少磁碟操作,但這對於long tail的讀取問題依然存在,因為這些文件的映射關系沒有提前放在內存中。

於是,Facebook 決定從頭研發圖片存儲系統,從前面我們可以看出,Haystack 的核心任務就是在處理每一次的請求中盡可能地減少磁碟操作。我們先來描述下 Haystack 讀取和上傳圖片流程是怎樣的,然後再來看其中的細節是如何處理的。

當發起一次圖片讀取請求的時候會通過一個事先構建好的 URL

http://///這個 URL 實際上顯示出了訪問的順序,先從外部 CDN 讀取,如果沒有,訪問內部 Cache,如果還是沒有,就直接訪問 Store Machine.(URL最後一部分提供了圖片的唯一標識)

用戶上傳圖片的時候先會上傳到 web 伺服器, 然後伺服器從Directory中找到一個可寫的physical volume,最後伺服器會給這個圖片生成一個唯一ID, 然後寫入到這個logical volume 所對應的所有physical volume中。

上面的過程中出現了幾個陌生的名詞,別著急,我們一個個來看。我們先來介紹 Haystack 的三個主要組件:

Store,Directory,Cache.

Store 是核心組件,負責圖片的存儲。Store 的容量決定了這個存儲系統的容量,整個 Store 組件由很多個 store machine 組成,store machine 的容量又由一系列的 physical volume 決定。

例:要提供 10TB容量,我們可分攤到 100 個 physical volume,每個 physical volume 提供 100 GB 的容量。這時候有的同學會問,那麼數據冗餘是怎麼解決的呢?Haystack 借鑒了普通硬碟中的 logical volume 的概念,將不同機器上的多個 physical

volume 組成了一個虛擬的 logical volume。

當存儲一張圖片的時候,實際上是存儲到了 logical volume 對應的所有 physical volume中。它們之間的映射關系連同其它的metadata都存儲在 Directory組件中。每個physicalvolume 中都存儲了上百萬張圖片,可以把它想像成一個巨大的 append-only 文件,然後通過 offset 來訪問文件。

我們來詳細看下這個文件到底是如何存放的,如何來達到減少磁碟操作目的的。對於每個這樣超大的文件,都由一個 superblock 和一系列的 needles 組成,每個 needle 就是每張圖片的信息。看下下面這張圖,它的結構就一目瞭然了。

每個needle包含的細節信息有圖片ID,圖片大小,圖片數據等等,還會有數據校驗的屬性。每個 store machine 都有若干個physical volume大文件, 為了提高檢索needles 的速度,在內存里為每個physical volume都維護了一張圖片I 到needle之間的映射表。

當store machine接收到讀取請求時,首先從內存映射表中找到相應的metadata, 然後通過offset從硬碟中讀取到整個needle, 通過數據校驗後返回。如果接收到的是上傳請求,會把組織好的needle追加到所有對應的physical volume文件中,並且更新內存里的映射表。如果是刪除操作的話,我們注意到下圖中有個Flags標志位其實就是用來標記是否是刪除的狀態,這樣一來就很簡單,直接在這個位置標記好,系統會在後面執行compaction 操作回收這些空間。

講到這里,一個正常流程的存儲過程已經很清楚了。這時候我們就需要考慮分布式系統一個必不可少的特性:容錯性。當一個 store machine 宕機的時候,理論上我們可以讀取所有的 physical volume 來重新構建內存映射表,但這就需要從磁碟重新讀取 TB 級別的數據,顯然是非常耗時和不高效的。為了解決這個問題,每個 store machine 為每個 physical volume 都維護了一個索引文件。這個索引文件類似於游戲中的存檔點 (checkpoint),它的結構和 physical volume 文件類似,保存了查找每個 needle 所需的屬性。為了性能,索引文件是非同步更新的(寫的時候非同步更新,刪的時候壓根不會更新),這就會帶來一個問題:索引文件有可能不是最新的。之前我們提到過,physical volume 文件是一個 append-only 的文件,索引文件也是。所以我們只需要在重啟 store machine 的時候,從後向前掃描 physical volume 文件找到那幾個沒有被索引的文件,加到索引里去就行了。對於被刪除的文件,在真正讀取完整 needle 數據的時候,通過檢查刪除標志位來更新內存映射表。

我們之前提到可以使用 CDN 來緩解系統壓力,但它無法很好地解決非熱點圖片的問題,並且如果 CDN 節點出現故障的話,沒有 Cache 這一層會對底層的存儲系統 Store 產生巨大的壓力。Cache 組件主要緩存了最近上傳的圖片,它的概念很簡單,實際上是一個分布式 hash table,通過圖片的 ID 為 key 可以找到對應的數據。Cache 接收從 CDN 或者瀏覽器直接發來的 HTTP 請求,但只有在以下兩個條件都滿足的情況下才會緩存圖片:

1) 請求來自用戶瀏覽器而不是來自 CDN

2) 請求的 store machine 是可寫的

這聽上去有些費解,條件 1 的原因是如果一個請求在 CDN 緩存中 miss 其實也會在 Cache 中 miss (如果一張圖片成為熱門的話,那也能在 CDN 找到),條件 2 的原因則是避免讓可寫的 store machine 進行大量讀操作,因為圖片通常在剛剛上傳後會被大量讀取,文件系統通常在只讀或者只寫而不是既讀又寫的時候性能比較好。

如果沒有 Cache 的話,可寫的 store machine 將會同時處理寫操作以及大量的讀操作,會導致性能的急劇下降。

現在我們只剩下 Directory 組件沒有講了。除了之前我們提到的存儲了 physical volume 到 logical volume 的映射關系以及圖片 ID 到 logical physical 的映射關系,它還提供負載均衡服務以及為每個操作選擇具體的 volume (因為寫操作的對象是 logical volume,讀操作的對象是 physical volume), 它還決定了一個請求是被 CDN 處理還是被 Cache 處理。Directory 還可以標記邏輯卷的狀態,在運維需要或者空間滿了的時候可以標記為只讀狀態。當往 Store 加新機器的時候,這些機器就會標記成可寫的,只有可寫的機器才能接受圖片上傳請求。這里有一個細節需要注意,圖片 ID 到 logical physical 的映射表肯定無法存放在單機內存,文章中也沒有交代具體實現。我們猜想可以使用 MySQL 分片集群和加上 Memcached 集群來實現。總的來講,Directory 實際上根據 metadata,然後結合各種策略,實現了整個系統的調度器。

本文描述了 Haystack 圖片存儲系統的主要脈絡,當然還有許多細節沒有提到,比如整個系統的容錯機制,如何實現批量寫操作等等。經過這幾年的發展,我們相信 Haystack 肯定也進行了更多的優化,現在一些開源的分布式存儲系統也被應用到實際的生產系統中,比如淘寶的 TFS,MooseFS 等等。我們會在後續的文章中比較這些系統之間的異同,總結出解決其中典型問題的通用方法。

㈡ 圖片存儲在什麼地方比較好數量比較多。。要那種永遠不會丟失的地方。。最好方便點

同意樓上的,圖片可以存儲在又拍雲存儲,又拍雲存儲採取的是分布式存儲,你的圖片會備份到三台伺服器上,一般來說,就算其中某台伺服器出現問題,也會迅速的轉接到其他的伺服器上,另外們又拍雲存儲有四條線路,電信,移動,聯通和教育四條線路,可以保證訪問者從各條線路以最快的速度訪問你的圖片

㈢ 集中式存儲和分布式存儲有什麼區別

區別:

1、物理介質分布不同。

集中存儲:物理介質集中布放。

分布存儲:物理介質分布到不同的地理位置。

2、視頻流上傳不同:

集中存儲:視頻流上傳到中心。

分布存儲:視頻流就近上傳,對骨幹網帶寬沒有什麼要求;可採用多套低端的小容量的存儲設備分布部署,設備價格和維護成本較低;小容量設備分布部署,對機房環境要求低。

3、對機房有要求不同:

集中存儲:對機房環境要求高,要求機房空間大,承重、空調等都是需要考慮的問題。

分布存儲:對骨幹網帶寬沒有什麼要求,可採用多套低端的小容量的存儲設備分布部署,設備價格和維護成本較低;。小容量設備分布部署,對機房環境要求低。



(3)圖片存儲分布式擴展閱讀:

集中存儲:

指建立一個龐大的資料庫,把各種信息存入其中,各種功能模塊圍繞信息庫的周圍並對信息庫進行錄入、修改、查詢、刪除等操作的組織方式。

分布式存儲系統:

是將數據分散存儲在多台獨立的設備上。傳統的網路存儲系統採用集中的存儲伺服器存放所有數據,存儲伺服器成為系統性能的瓶頸,也是可靠性和安全性的焦點,不能滿足大規模存儲應用的需要。

分布式網路存儲系統採用可擴展的系統結構,利用多台存儲伺服器分擔存儲負荷,利用位置伺服器定位存儲信息,它不但提高了系統的可靠性、可用性和存取效率,還易於擴展。


網路-集中存儲

網路-分布式存儲系統

熱點內容
麥塊有什麼伺服器 發布:2024-12-25 22:12:58 瀏覽:374
網上比較火的安卓系統是什麼 發布:2024-12-25 21:57:06 瀏覽:993
資料庫一個的和 發布:2024-12-25 21:50:40 瀏覽:465
鈣化分析演算法 發布:2024-12-25 21:49:51 瀏覽:462
運用計演算法 發布:2024-12-25 21:49:46 瀏覽:943
微信安裝安卓707什麼意思 發布:2024-12-25 21:38:15 瀏覽:882
演示文稿如何取消密碼 發布:2024-12-25 21:21:18 瀏覽:99
最近上傳視頻 發布:2024-12-25 21:05:39 瀏覽:396
php招聘源碼 發布:2024-12-25 21:05:38 瀏覽:991
c語言輸入數組賦值 發布:2024-12-25 21:01:43 瀏覽:655