我所了解的Facebook的架构

• Web前端使用PHP。Facebook的HipHop编译器会将它们转换成C++然后使用g++编译,这样就提供了一个高性能的模版和web逻辑执行层。
• 由于完全依赖静态编译的限制， Facebook已经开始开发一个HipHop的解释程序和HipHop虚拟机，它会将PHP代码转换成HipHop字节码。
• 业务逻辑使用Thrift包装成服务。服务可能使用PHP, C++ 或者 Java开发， 也可能有其它语言，这依赖于服务需求 由Java实现的服务并不使用某种企业应用服务器，而是使用Facebook自己定制的应用服务器. 看起来好像是重新发明轮子，但是这些服务通常是使用Thrift暴露或者使用，使用tomcat或者Jetty都太重了
• 持久化采用MySQL, Memcached [5], Hadoop’s HBase [6]. Memcached为MySQL做通用缓存
• 离线处理使用Hadoop 和 Hive. logging, clicks 和 feeds数据的传输使用Scribe 。 这些数据集中存储在HDFS（使用Scribe-HDFS ）, 因此可以使用MapReduce做扩展分析。
• 自有技术BigPipe用来加速页面的渲染（使用pipelining logic） Varnish Cache用作HTTP网关，由于它的高性能和效率作为他们的首选
• 数十亿的用户上传的招聘使用Haystack处理。Facebbook开发的一个特别的存储方案。提供底层的优化和append-only writes。
• Facebook消息系统基于自己的架构， 显著利用分片sharding和动态集群管理. 业务逻辑和持久化被封装进一个称之为’Cell’模块. 每个Cell处理一部分的用户; 当用户增加时新的Cell可以加进来。 持久化使用HBase。
• Facebook消息搜索引擎建立在存储在HBase上的反向索引。
• Facebook消息搜索引擎的细节未知
• 输入提示搜索使用一个定制的存储和检索算法
• Chat基于Epoll服务器，使用Erlang开发，通过Thrift访问。
• 他们还建立了一个自动化的系统，可以对监控警报进行响应，启动一个合适的修补流程或者在无法自动修补的情况下通知人力来修补。

Facebook估计有超过6万台服务器。 他们的最新的位于Oregon Prineville数据中心使用完全自己设计的硬件，这是最近退出的开放计算项目。 Memcached进程存储了 300 TB的数据 Hadoop/Hive集群由3000台服务器组成，每台服务器8个核, 32 GB 内存, 12 TB硬盘，集群总共2万4千和核, 96 TB内存和36 PB硬盘 每天1000亿次点击，500亿张照片，3 万亿个对象被缓存, 每天130 TB日志 （2010年7月统计）