炙手可热的 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.希望和楼主交换下链接
本人也是研究网站体系架构的
http://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的几率很小