① 网站前端服务包括DNS服务、CDN服务、反向代理服务、静态资源服务等。对WikiPedia而言，80%以上的用户请求可以通过前端服务返回，请求不会到达应用服务器，这就大大减轻了应用服务器和存储端的压力。
② CDN服务对于Wikipedia性能优化居功至伟。因为用户查询的词条大部分集中在比重很小的热点词条上，将这些词条内容页面缓存在CDN服务器上，而CDN服务器又部署在离用户浏览器最近的地方，用户请求直接从CDN返回，响应速度非常快，这些请求甚至根本不会到达Wikipedia数据中心的Squid反向代理服务器，服务器压力减小，节省的资源可以更快地处理其他未被CDN缓存的请求。
③ Wikipedia前端架构的核心是反向代理服务器Squid集群，大约部署数十台服务器。请求通过LVS负载均衡地分发到每台Squid服务器，热点词条被缓存在这里，大量请求可直接返回响应，请求无需发送到Apache 服务器，减轻应用负载压力。Squid 缓存不能命中的请求再通过LVS发送到Apache应用服务器集群，如果有词条信息更新，应用服务器使用Invalidation Notification 服务通知Squid缓存失效，重新访问应用服务器更新词条。
2）服务端
后端优化最主要的手段是使用缓存，将热点数据缓存在分布式缓存系统的内存中，加速应用服务器的数据读操作速度，减轻存储和数据库服务器的负载。
Wikipedia的缓存使用策略如下：
① 热点特别集中的数据直接缓存到应用服务器的本地内存中，因为要占用应用服务器的内存且每台服务器都需要重复缓存这些数据，因此这些数据量很小，但是读取频率极高。
② 缓存数据的内容尽量是应用服务器可以直接使用的格式，比如HTML格式，以减少应用服务器从缓存中获取数据后解析构造数据的代价。
③ 使用缓存服务器存储 session对象。
④ 相比数据库，Memcached的持久化连接非常廉价，如有需要就创建一个Memcached连接。
3）MySQL数据库优化
① 使用较大的服务器内存。在Wikipedia应用场景中，增加内存比增加其他资源更能改善MySQL性能。
② 使用RAID0磁盘阵列以加速磁盘访问，RAID0虽然加速磁盘访问，但是却降低了数据库的持久可靠性，数据的可靠性问题可以通过MySQL主从复制、数据异步备份等手段来解决。
③ 将数据库事务一致性设置在较低水平，加快宕机恢复速度。
④ 如果Master数据库宕机，立即将应用切换到Slave数据库，同时关闭数据写服务，这意味着关闭词条编辑功能（通过约束业务获得技术方案选择余地）。
二、Facebook
1、Facebook的数据量
- 每月的页面浏览量：570000000000 （5700亿）
- 照片数量超过其他图片网站的总和（包括诸如Flickr等网站）
- 每个月有超过30亿张照片上传
- 每秒可以处理120万张照片，这还不包括CDN处理的照片
- 每月处理超过25亿条内容 （状态更新，评论等）
- 服务器超过30,000台（此数据为2009年的数据）
2、Facebook的主要架构
Facebook使用LAMP（Linux、Apache、MySQL、PHP）作为技术构架，为了配合其他大量的组件和服务，Facebook对已有的方法做了必要的改变、拓展和修改。比如：
- Facebook依然使用PHP，但已重建新的编译器，以满足在其Web服务器上加载本地代码，从而提升性能；
- Facebook使用Linux系统，但为了自身目的，也已做了必要的优化，尤其是在网络吞吐量方面；
- Facebook使用MySQL，也对其做优化；
- 还有定制的系统，比如：
Haystack — 高度可扩展的对象存储，用来处理Facebook的庞大的图片；
Scribe — Facebook的日志系统。
三、Google App Engine
Google App Engine是一款PaaS服务，帮助用户快速搭建web应用，并且无需再运维花费大量的时间和精力。
主要功能有：支持Web应用，提供持久存储空间，对应用自动扩展和负载均衡，支持Email、用户认证和缓存等多种服务等等。
