现在的位置: 首页 > 综合 > 正文

Facebook的可扩展性体系结构

2013年05月22日 ⁄ 综合 ⁄ 共 1136字 ⁄ 字号 评论关闭

Facebook是基于LAMP的一个超大规模应用。其支持可扩展性的核心结构部件有:Memcache (一个分布式的基于内存的Cache), Thrift (跨语言的Remote Procedure Call (RPC) library)和 Scribe (一个C++ logging library). 它支持1.2亿用户,每月超过500亿网页访问量,5万多个应用程序和40万程序员。

这里是Facebook 工程总监的演讲:Facebook: Science and the Social Graph。里面谈到了上述技术。http://glinden.blogspot.com/2008/05/scaling-facebooks-databases.html 
有关于数据库的扩展性讨论。Facebook有1,800个MySQL数据库组成900个主-从对,但是只要二个数据库管理员。这里http://sizzo.org/wp/talks有关于Facebook多级Cache的描述。
这一篇博客描述了Facebook Chat的结构设计:Facebook Chat。其最大的挑战是实时监控用户的上线,下线状态;其次是实时的消息通信。分布式的容错设计通常是将Model和View分开,View的数据是长存在数据库中。这样当一个短暂的访问(只访问其相关数据)请求出错时,数据访问中间层可以发现不在缓存或数据库失效等错误,进而重试其他操作如访问数据库或访问备份数据库。但是这种实际并不适合Chat。因为Chat的应用是长时间的有状态(stateful)访问请求,而且数据不是关系型的。
所以Facebook的Chat用了一个C++的消息记载(logging)子系统和用Erlang的epoll-driven Web Server支持长时间HTTP请求的基于内存的联机用户交谈。epoll 是一种I/O事件通告(event notification) 机制。两个子系统都支持集群和分区以达到可靠性和高效的容错。为什么用Erlang?因为Erlang简直就好像是为解决这个问题设计的。Erlang是一个函数式并发语言,有非常轻量级的用户空间进程,不共享的消息传递语义,内建的分布式功能,还有经过二十年大规模实时系统部署检验的崩溃回复(crash-recover)机制。
Erlang缺点是和系统其他部分的通信。粘合PHP,Javascript, Erlang,和C++并不容易。好在Thrift很好地解决了这个问题。当然开发能够支持一夜之间从零到七千万用户的扩展性是不可以一蹴而就的。我们采用一种叫做“无形发布(dark launch)”的方法来模拟其效果。在此期间,网页上没有用户可用界面元素,但是在后台会发送信息请求及模拟消息收发。

抱歉!评论已关闭.