.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/）。