導讀：毫無疑問，作為全球最領先的社交網絡，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中並沒說這些集群具體怎么做分布和冗余備份的。
轉自：http://www.csdn.net/article/2011-06-10/299486