Facebook:如何管理10億用戶的數據?

Facebook用戶數量,已經突破10億大關。Facebook在發展期間,所實現的技術成就,成為了IT行業工程師關注的話題。究竟Facebook取得了哪些技術成就呢?Facebook前工程部門總監,在問答網站Quora上,對這一問題作出回答。無論對於IT行業的投資者還是使用者,這些回答都有著指導意義。

  以下是文章全文:

  我在Facebook的基礎架構軟件開發團隊,工作了5年,並且參與了多數項目的開發。我認為在Facebook時,最偉大的成就是Memcache/MySQL集群。一年前,我離開Facebook的時候,這個集群中已經擁有超過1萬億對象(沒錯是萬億),每秒請求數量超過10億,處理時間通常不超過1毫秒。這一集群,在多個數據中心之間,保持了良好的一致性,並且很少出現停機的情況。

  實際上,我們取得的真正成就,與Memcache和MySQL並沒有多大的關係隨著時間的推移,這些都將會被新的"技術"所取代,但是這裡真正重要的技術,是讓數量如此龐大的機器,快速、可靠的協同工作。這並不同於通常意義上,人們在詢問"你用的是什麼樣的技術?"時,所指代的東西,但是這一方面確實會出現很多有趣的創新。

  這包括算法方面的技巧,如分片(Shard)、分區(Partition)、緩存數據,以及保持分佈式數據的一致等。雖然像"部署和監控"這樣的事情,聽上去似乎有些很普通,但是當一切到了Facebook這樣大的規模,就變的不再簡單。

  以下是我們面臨的一些具體的挑戰:

  1. 數據中心間的一致性

  Facebook是一個實時的應用程序,這也就意味著,無論世界哪一個角落的數據發生改變,都需要立即顯示到所有其他的地方。因此這對一致性有著令人驚訝的高要求。

  常常有人說,"哦,Facebook只是一個讓人覺得挺有趣的社交網站,一致性並沒有那麼重要。"但是如果信息出現的時間順序有問題,或者有的消息會憑空消失,那麼這些情況 就很容易惹惱用戶。以下是我們在2007年,創建首個地理分佈數據中心時的老博客:《Scaling Out Facebook》

  現在回頭看,雖然這個方案聽起來有些嚴格,但是它真的很有用,而且幫助讓我們達到了現在這個巨大得規模。而現在的設置顯然已經變得更為複雜。

  2. 網絡流

  Facebook的頁面,需要很多小塊的數據,而這些往往並不容易聚集。所以我們經常看到的一個模式,是一台服務器,會從大量其他的服務器處,要求大量小的對象。而這裡的問題在於,如果所有的服務器都在同時進行回复,你就會通過請求服務器的rack switch和網絡適配器(NIC)突然獲得大量的數據包,然後就會有數據包被丟棄。這就是學術文獻中所謂的"TCP incast",而我們解決這個的方法,是對機器上發送的請求進行截流。

  而當故障(failure)出現的時候,網絡問題往往會變得更加糟糕。大多數軟件在沒有從另一個服務器獲得回應時,都會重新發送另外一個數據包。不幸的是,大多數時候,沒有獲得回复的原因,恰恰是另外一個服務器已經過載。因此,當一個服務器過載嚴重,而無法作出及時回复時由於大量請求會重新發送,它的數據流量會瞬時增長一倍。

  我們投入了大量的時間用於算法研究,並希望無縫處理"重試"(retry)可以解決的小問題,但是也需要確保不會在出現大故障的時候失去控制,因為那時候重試只會讓事情變得更糟。

  3. 高速緩存配置

  這裡有很多東西需要平衡如果你有大的對象,你希望通過機器進行傳遞開,這樣你就可以進行並行處理;但是如果是小的對象,你則希望它們可以同時出現,這樣在RPC調用會給你帶來多個對象。而Facebook需要的往往是後者,因此我們在改善"每RPC對像數量"方面,使用了很多的技巧。

  很多情況都需要分離不同工作負載的對象,進行不同的調整。我們還花了大量的的時間,搞清楚是什麼內存之中最具有成本效益的東西,以及何時非規範化能有用(實踐中的大多數時候,非規範化並沒有什麼實質性的幫助)。

  4. 失敗處理

  正如前面網絡部分所提到的,有的時候一些方法能夠解決小問題,但往往會讓大問題變得更糟。例如,我有一個算法,給隨機服務器發送請求,如果它沒有得到答复,就會把請求重新發送到另一個不同的隨機服務器上,直到它得到一個答复才會停止。如果你只有一兩個機器出現問題的時候,這種方法顯然會表現很好。但是如果你一半的機器都出現問題,那麼就成了一場災難。

  這時,所有其他的機器的負荷都會突然加倍,而如果一半的機器都出現問題,很有可能意味著有著負載已經過高。這時候,你需要做的事情,是檢測過載情況,並且減少負載。重要的是,要記住計算機科學意義上的實時系統,意味著:一個遲到的回應,就是一個錯誤的回應。

  放棄一個請求的時候,人們往往會感覺不好,不過這往往是最好的處理方式在出現問題的時候,最大化正確答案的數量才是最正確的。

  另一種常見的模式是,當有些東西變慢的時候,就建立一個較大的隊列(queue),然後讓所有事情慢下來,減少負載。這可以是一個很棘手的算法,因為你可能在正常操作中也需要一個深隊列,來處理瞬間突發流量。

  5. 提升Memcache和MySQL

  我們討論到數據庫/緩存集群的時候,人們總會想到Memecache和MySQL。我們在Memcache方面做了大量的工作,以提升吞吐量大量的分析和解決方法,這大多數都是在網絡棧中。因此很多這樣的工作,實際上是在Linux內核中發生的。

  在MySQL中,則是關於以一種合理的方式,獲得磁盤上的數據,並且把內存中最有用的東西放到緩存裡。馬克·卡拉漢(Mark Callaghan)的博客中,有著大量的信息:《高可用性MySQL》( http://mysqlha.blogspot.com/)。

  6. Meta

  在這篇文章中,我記錄了我們所遵循的原則:《讓Facebook的用戶超過5億》



--
由 網路行銷-網路賺錢 於 1/28/2013 10:45:00 下午 張貼在 *
arrow
arrow
    全站熱搜

    efortune4 發表在 痞客邦 留言(0) 人氣()