【IT168技术文章】
在QCon 2008 (旧金山站) 上Facebook 做的这个技术分享有不少值得借鉴的东西。
设计原则
尽可能的使用开源软件，并且在需要优化的时候进行优化
Unix哲学。包括，模块化原则；整合化原则；清晰化原则等
任何组件具备扩展性
最小化故障影响
简化，简化，简化！
架构概览
Facebook是LAMP的坚定支持者，也差不多是用LAMP(或许用LAM2P更适合)实现的最大的动态站点。
基础组件加上服务，中间用自己实现的一些工具进行粘合。其中关于运维细节的事情基本不会说出来的，这是很多公司的软实力所在。
PHP经验
MySQL经验
主要用于做Key-Value类型的存储操作，数据随机分布在多台逻辑实例上，访问多数基于全局ID。
逻辑实例分散在多台物理主机上(超过1800台)，负载均衡在物理层进行。
不做读复制。
尽量不做逻辑数据迁移(成本太高)。
不做JOIN操作(豆瓣在QCon上也阐述了这一点)。数据是随机分布的，关联操作反而带来了极大的复杂度。
对于数据访问，主要的操作集中在最新的数据上，针对这部分做优化，旧的数据进行归档。
在中心DB绝不存储非静态数据。
使用服务或者Memcached进行全局查询。
Memcached经验
参见我以前的笔记：Facebook的Memcached扩展经验。Facebook对Memcached做了不小的改进。另外，顺便说一下，前两天Memcached刚在1.2.7发布几天之后又发布了新版本1.2.8，修正了一些问题。
一个比较有价值的是关于个人页面数据的获取的描述。这个就完全是需要做单页面Benchmark的细致活儿了，可能还需要产品经理能够理解工程师的"抵抗"。
获取个人信息数据：通过Cache，隐性通过用户所在的DB获取(基于User-ID获知DB)
获取朋友连接信息：通过Cache，否则的话通过DB(基于User-ID获知DB)
并行抓取每个朋友的10个照片相册ID，从Cache抓取，如果失效，再从DB抓取(基于相册ID)
并行抓取最近相册中的照片数据
运行PHP把整个业务逻辑跑出来
返回数据给用户
然后是对Facebook非LAMP体系的东西做了一番介绍，基本上也开源了。最后参考两个架构图。
FacebookNewsFeed的架构示意图
Facebook搜索功能的架构示意图
