网址: http://www.dbanotes.net/arch/facebook_php.html
炙手可热的 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 是最主要的。在这两个环节上下功夫，受益/开销比要大于另外几个环节。
-----------------------------------------------------------------------------------------------------------------------------------------------
架构学习—facebook
Facebook是一个社会化网络站点，它于2004年2月4日上线。每个用户在facebook上有自己的档案和个人页面，用户之间可以通过各种方式发生互动：留言、发站内信，评论日志。虽然目前在国内无法访问facebook，但其强悍的技术架构还是值得我们去研究分析和总结的，或许我们可以从中得到一点启发。另外，本文很多内容也是来自互联网，如有侵权方面的内容请留言，我会及时处理。
facebook的设计原则是模块化原则、整合化原则、清晰化原则，其架构设计的目标是简单、高效。facebook的架构是基于LAMP，差不多是用LAMP实现的最大的动态站点，以下是facebook架构图概览
PHP经验：
MySql经验：
主要用于做Key-Value类型的存储操作，数据随机分布在多台逻辑实例上，访问多数基于全局ID。
逻辑实例分散在多台物理主机上(超过1800台)，负载均衡在物理层进行。
不做读复制。尽量不做逻辑数据迁移(成本太高)。
不做JOIN操作(豆瓣在QCon上也阐述了这一点)。数据是随机分布的，关联操作反而带来了极大的复杂度。
对于数据访问，主要的操作集中在最新的数据上，针对这部分做优化，旧的数据进行归档。
在中心DB绝不存储非静态数据。
使用服务或者Memcached进行全局查询。
Memcached经验：
一个比较有价值的是关于个人页面数据的获取的描述。这个就完全是需要做单页面Benchmark的细致活儿了，可能还需要产品经理能够理解工程师的"抵抗"。
获取个人信息数据：通过Cache，隐性通过用户所在的DB获取(基于User-ID获知DB)
获取朋友连接信息：通过Cache，否则的话通过DB(基于User-ID获知DB)
并行抓取每个朋友的10个照片相册ID，从Cache抓取，如果失效，再从DB抓取(基于相册ID)
并行抓取最近相册中的照片数据
运行PHP把整个业务逻辑跑出来
FacebookNewsFeed的架构示意图：
Facebook搜索功能的架构示意图
