炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流，逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。
Cache 为 王
任何一个成功的站点都有一套最合适自己的 Cache 策略。
Note：这个层次图画的稍微有点问题，不是严格从上到下的。
The Alternative PHP Cache , APC
Facebook 平均每个用户每天要访问超过 50 个页面，PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层，Facebook 采用了 APC。
Lucas Nealan 的 PPT 举了一个例子，一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下，性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。
Memcached 层
APC Cache 的是非用户相关的信息，而用户相关的数据 Cache 当然是在 Memcached 中。
Facebook 部署了超过 400 台 Memcached 服务器，超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码，包括 UDP 的支持和性能上的提升(性能提升超过 20%)。
程序 Profiling
Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目，这也是不可或缺，也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。
补充一下：语言的选择
为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: "Languages's don't Scale, Architecture Scale"。
从 80-20 的原则看，APC 和 Memcached 是最主要的。在这两个环节上下功夫，受益/开销比要大于另外几个环节。
(上面的图是从 Lucas Nealan 的文档截的，版权所有是他的)
--EOF--
这个服务器的数量还是比较恐怖的。
不知道他们使用什么样的架构，如何管理
我怎么记得facebook是ruby开发的？？
你看看这个
http://highscalability.com/friends-sale-architecture-300-million-page-view-month-facebook-ror-app
#
The Platform
# Ruby on Rails
# CentOS 5 (64 bit)
# Capistrano - update and restart application servers.
# Memcached
# MySQL
# Nginx
# Starling - distributed queue server
# Softlayer - hosting service
# Pingdom - for website monitoring
# LVM - logical volume manager
# Dr. Nics Magic Multi-Connections Gem - split database reads and writes to servers
楼上的，所提供的链接说的是一个叫 friend for sale 的facebook 功能应用是用ror开发的。开发这个应用的可不是facebook做的。
hi Fenng,我下载的Lucas Nealan 的pdf上没有你文章中关于 APC 的那个结构图,是不是我下载的不pdf不全. 能把你下载的URL 告诉下吗? 谢谢
@tesge
我漏掉了,搜索一份叫做 apc@facebook 的 PDF 文档
评论也这么难发呀。。
PHP的缓存，现在Xcache也不错，还是国人开发
不错呀，真长见识了。
悄悄问一下
Languages's don't Scale, Architecture Scale
这句到底是什么意思！
Languages's don't Scale, Architecture Scale
very very reasonable!
很可惜国内的很多应用
在处于争论到底JAVA,RUBY,还是PHP,ASP.NET哪种好的程度上
只是我没想到他们还在用APC
似乎APC已经停滞开发很久了.
如果是400台的memcached.我比较关心他们怎么处理memcached非持久性数据保存的问题
因为万一其中一台挂了.所有cached的数据就要从头再去DB里面读取.这样性能会一下子下降很多.
PS.希望和楼主交换下链接
本人也是研究网站体系架构的
www.hiadmin.com
为什么说“似乎APC已经停滞开发很久了.”
让我感觉老外说中国男人都留着辫子
代码罐头 的评论:
因为万一其中一台挂了.所有cached的数据就要从头再去DB里面读取.这样性能会一下子下降很多.
设计上可以每台cache分别对后台M台db散列进行缓存。
这样一台cache失效时，台每台db只要承受全部数据的1/N（N是cache数量）的操作压力（最优化情况下），所以这就是DB处理的底线了。
我觉得比较复杂，不过大公司应该可以实现吧。呵呵
ultraice#gmail#com
Languages's don't Scale, Architecture Scale
砖头木头不重要，重要的是如何设计。
这篇文章有点老……
facebook之所以如此庞大的硬件开销，恰恰是因为，当初开始设计的时候就没有进行有效的软件框架设计。
php最大的好处就是简单，宜用，我用3天学完，2个星期就开发一个生物实验用的信息平台。
但是，问题在于php不能很好的让后台和前台有效分隔，而后台的可扩展性和分不性根本就是依靠于php不同的框架，其实说白了facebook后台用了很多C/C++还有Java之类的语言来辅助。
真是无知者无畏啊……
http://goo.gl/CA78
Facebook 每位工程师服务 120 万名用户 v.s. Google 1:190,000 v.s. Amazon 1:96,000 v.s. Microsoft 1:75,000
这个是做多副本轮询，一个挂了还有其他几个副本，直到全部挂了才会去db里面重建，当然在全挂之前个mc服务器会自动修复挂掉的副本，所以去读db的几率很小