淺談Facebook的伺服器架構(組圖)

導讀：毫無疑問，作為全球最領先的社交網絡，Facebook的高性能叢集系統承擔了海量資料的處理，它的伺服器架構一直為業界衆人所關注。CSDN部落客​​yanghehong​​在他自己最新的一篇部落格​​《 Facebook的伺服器架構》​​中分享了他的看法。

大體層次劃分

Facebook的架構可以從不同角度來換分層次。

一種是：一邊是PHP整的經典的LAMP stack；另外一個是非PHP整的各種service。

Facebook的頁面從剛創立的時候紮克伯格寫的，到現在，都用PHP開發。後端有用各種語言開發的service。它們之間用跨語言的thrift RPC通信(Scribe也是建立在Thrift之上)。

另外一個角度劃分的層次是：

前面是負載局衡器(沒說是用硬體的還是軟體的)；負責配置設定 前端的Web伺服器， Web伺服器是用PHP來聚合資料；最後面是 Services，Memcached和資料庫。

有意思的是對後面三種的定性：

Services – 快速，複雜； 自己開發的業務程序，來實作複雜的業務邏輯，速度快。

Memchached – 快速，簡單；Memchached做簡單的key-value緩存，服務應用快速的讀請求。

資料庫 – 緩慢，持久。資料庫做持久存儲，磁盤IO自然慢，不過有memcached做緩存沒關系。

NewsFeed的架構

寫：

Bob更新狀态，Web伺服器上的PHP程式除了将内容到MySQL資料庫之外，也将該行為動态的ID通過Scribe發到一個Leaf Server上(根據Bob的使用者ID選的Leaf Server)。

讀：

另一個人Alice打開Facebook，加載首頁，PHP程式向Aggregator伺服器查詢(Thrift調用)，Aggregator從若幹個Leaf Server裡頭讀出Alice的朋友的所有行為動态/action的前四十個，aggregator做聚合和一定的排序，傳回給PHP程式。

PHP程式獲得這些行為動态的ID之後，從Memcached中讀出這些ID對應的内容，如Memcached沒有則從MySQL資料庫中讀，彙聚後生成HTML傳回給浏覽器。

Chat的架構

頁面請求，仍WEB伺服器處理(PHP)處理，當然也依賴web tier之後的各種Service。比如檢視消息曆史啊，線上使用者清單啊，發送聊天消息啊。

接收聊天消息，則沒通過PHP伺服器，而是專用的用Erlang寫的Channel伺服器來處理，通過​​long-polling​​來接收聊天消息。Channel伺服器是Chat服務的核心部件。發送的消息通過web tier發到Channel伺服器。

後方有用C++寫的chatlogger伺服器來做曆史記錄的讀寫。

同樣也用C++寫了presence伺服器來從channel伺服器彙集線上狀态。

系統的簡化結構如下圖所示：

Web tier, chatlogger, presence, channel 都是多個伺服器組成的叢集。

Channel伺服器有根據User ID做分區，每個分區由一個高可用的Channel叢集服務。

Web tier, chatlogger, presence，在公開的文章和PPT中并沒說這些叢集具體怎麼做分布和備援備份的。