揣测一下Facebook的服务器架构

导读&＃xff1a;毫无疑问&＃xff0c;作为全球最领先的社交网络&＃xff0c;Facebook的高性能集群系统承担了海量数据的处理&＃xff0c;它的服务器架构一直为业界众人所关注。CSDN博主yanghehong在他自己最新的一篇博客《 Facebook的服务器架构》中分享了他的看法。

大体层次划分 

Facebook的架构可以从不同角度来换分层次。 

一种是&＃xff1a;一边是PHP整的经典的LAMP stack&＃xff1b;另外一个是非PHP整的各种service。

Facebook的页面从刚创立的时候扎克伯格写的&＃xff0c;到现在&＃xff0c;都用PHP开发。后端有用各种语言开发的service。它们之间用跨语言的thrift RPC通信(Scribe也是建立在Thrift之上)。 

另外一个角度划分的层次是&＃xff1a;

前面是负载局衡器(没说是用硬件的还是软件的)&＃xff1b;负责分配前端的Web服务器&＃xff0c;Web服务器是用PHP来聚合数据&＃xff1b;最后面是Services&＃xff0c;Memcached和数据库。

有意思的是对后面三种的定性&＃xff1a;

Services – 快速&＃xff0c;复杂&＃xff1b;自己开发的业务进程&＃xff0c;来实现复杂的业务逻辑&＃xff0c;速度快。

Memchached – 快速&＃xff0c;简单&＃xff1b;Memchached做简单的key-value缓存&＃xff0c;服务应用快速的读请求。

数据库– 缓慢&＃xff0c;持久。数据库做持久存储&＃xff0c;磁盘IO自然慢&＃xff0c;不过有memcached做缓存没关系。 

NewsFeed的架构 

写&＃xff1a;

Bob更新状态&＃xff0c;Web服务器上的PHP程序除了将内容到MySQL数据库之外&＃xff0c;也将该行为动态的ID通过Scribe发到一个Leaf Server上(根据Bob的用户ID选的Leaf Server)。 

读&＃xff1a;

另一个人Alice打开Facebook&＃xff0c;加载主页&＃xff0c;PHP程序向Aggregator服务器查询(Thrift调用)&＃xff0c;Aggregator从若干个Leaf Server里头读出Alice的朋友的所有行为动态/action的前四十个&＃xff0c;aggregator做聚合和一定的排序&＃xff0c;返回给PHP程序。  

 

PHP程序获得这些行为动态的ID之后&＃xff0c;从Memcached中读出这些ID对应的内容&＃xff0c;如Memcached没有则从MySQL数据库中读&＃xff0c;汇聚后生成HTML返回给浏览器。    

Chat的架构 

页面请求&＃xff0c;仍WEB服务器处理(PHP)处理&＃xff0c;当然也依赖web tier之后的各种Service。比如查看消息历史啊&＃xff0c;在线用户列表啊&＃xff0c;发送聊天消息啊。 

接收聊天消息&＃xff0c;则没通过PHP服务器&＃xff0c;而是专用的用Erlang写的Channel服务器来处理&＃xff0c;通过long-polling来接收聊天消息。Channel服务器是Chat服务的核心部件。发送的消息通过web tier发到Channel服务器。 

后方有用C&＃43;&＃43;写的chatlogger服务器来做历史记录的读写。 

同样也用C&＃43;&＃43;写了presence服务器来从channel服务器汇集在线状态。 

系统的简化结构如下图所示&＃xff1a;  

Web tier, chatlogger, presence, channel 都是多个服务器组成的集群。

Channel服务器有根据User ID做分区&＃xff0c;每个分区由一个高可用的Channel集群服务。

Web tier, chatlogger, presence&＃xff0c;在公开的文章和PPT中并没说这些集群具体怎么做分布和冗余备份的。