1、大型 Web2.0 站点构建技术初探一、 web2.0 网站常用可用性功能模块分析二、 Flickr 的幕后故事三、 YouTube 的架构扩展四、 mixi.jp：使用开源软件搭建的可扩展 SNS 网站五、 Technorati 的后台数据库架构六、 通过了解 MySpace 的六次重构经历,来认识分布式系统到底该如何创建七、 从 LiveJournal 后台发展看大规模网站性能优化方法八、 说说大型高并发高负载网站的系统架构一、 web2.0 网站常用可用性功能模块分析Web 2.0 网站是指将传统的网站构架（平台、内容源、用户、传播方式等）转化到以用户为核心的网站构架上来，包括一系列体现
2、 web2.0 概念的元素、定位和创意。web2.0 网站在构架上须体现两大宗旨，即强大的后台系统和简单的前台页面，也即提供良好的用户体验，体现以人为本，技术服务人类的宗旨。web2.0 网站常用功能块通常包括以下几大项：1. Tag 标签功能块Tag(中文叫做“标签“) 是一种新的组织和管理在线信息的方式。它不同于传统的、针对文件本身的关键字检索，而是一种模糊化、智能化的分类。网页使用 Tag 标签的好处：为页面设置一个或者多个 Tag 标签可以引导读者阅读更多相关文章，为别人带去流量同理也为自己带来流量。可以帮助读者及时了解一些未知的概念和知识点，提高用户体验。Tag 是人的意志和趋向的体
3、现，Tag 可以帮助你找到兴趣相投的人。基于以上优势，Tag 标签代替了传统的分类法，成为 web2.0 网站使用率最高的功能块（与其说是功能块倒不如说是一种内容导航和内容组织形式） 。一句话：Tag 标签是一种更灵活的分类方法，功能在于引导，特点是无处不在，体现智能性、模糊性和趋向性。2. RSS 订阅功能块RSS 是在线共享内容的一种简易方式（也叫聚合内容，Really Simple Syndication） 。通常在时效性比较强的内容上使用 RSS 订阅能更快速获取信息，网站提供 RSS 输出，有利于让用户获取网站内容的最新更新。网络用户可以在客户端借助于支持 RSS 的聚合工具软件（例
4、如 SharpReader,NewzCrawler、FeedDemon） ，在不打开网站内容页面的情况下阅读支持 RSS 输出的网站内容。RSS 订阅的方式：订阅到客户端软件如周伯通、遨游浏览器 RSS 阅读、Foxmail RSS 阅读等，此方式使用者较多订阅到在线阅读（聚合类）门户网站如 Google Reader，Yahoo Reader，抓虾、Gougou 等，省去了安装 RSS 阅读器的麻烦订阅到在线单用户聚合器如 Lilina 等，比较灵活RSS 订阅功能的最大好处是定向投递，也就是说 RSS 机制更能体现用户的意愿和个性，获取信息的方式也最直接和简单，这是RSS 订阅功能备受青睐
5、的一大主要原因。3. 推荐和收藏功能块说到推荐功能，不仅 web2.0 网站在大量使用，传统的以 cms 平台为代表的内容模式的网站也在大量使用，推荐功能主要是指向一些网摘或者聚合类门户网站推荐自己所浏览到的网页。当然，一种变相的推荐就是阅读者的自我收藏行为，在共享的模式下也能起到推荐的作用。比较有名的推荐目标有以 del.icio.us 为代表的网摘类网站包括国内比较有名气的 365key、和讯网摘、新浪 vivi、天极网摘等。这里值得一提的是前段时间曾涌现了大批网摘类网站，但他们坚持活下来的好像没有几个了，推荐使用前面提到的这几个网摘门户，人气基本上是使最旺的。4. 评论和留言功能块web
6、2.0 强调参与性，强调发挥用户的主导作用，这里的参与性除了所谓的订阅、推荐功能外更多地体现在用户对内容的评价和态度，这就要靠评论功能块来完成。一个典型的 web2.0 网站或者说一个能体现人气的 web2.0 网站都会花大量篇幅来体现用户的观点和视觉。这里尤其要提到 web2.0 中的带头老大 web blog，评论功能已经成为博客主人与浏览者交流的主要阵地，是体现网站人气的最直观因素。评论功能块应用在博客系统中实际上已经和博客内容相分离，而更好的应用恰恰是一些以点评为主的 web2.0 网站比如豆瓣、点评网等，这里的评论功能块直接制造了内容也极大地体现了网站的人气，所以说评论功能块是 we
7、b2.0 网站最有力的武器。5. 站内搜索功能块搜索是信息来源最直接的方式之一，无论你的网站是否打上web2.0 的烙印，搜索对于一个体系庞大、内容丰富的大型网站都是非常必要的。Tag 标签在某种程度上起到搜索的作用，它能够有效聚合以此 Tag 为关键词的内容，但这种情况的前提是此 Tag 标签对浏览者是可见的，也就是说当 Tag 标签摆在浏览者的眼前时才成立，而对于那些浏览者想要的信息却没有 Tag 标签来引导时搜索就是达到此目的的最好方法。对于 web2.0 网站，站内搜索以标题或者 Tag 为搜索域都能起到好的效果，但本人不建议使用内容搜索域，因为这不符合搜索的高效性原则。同时，具有突出
8、关键词的内容往往都可以用 Tag 标签来引导，因此使用内容域来搜索实际上是一种浪费服务器资源的行为，而且搜索结果的准确性将大打折扣。6. 群组功能块我为什么要把群组作为 web2.0 网站的功能块来分析呢，因为群组是 web2.0 网站的一大特点，也是 web2.0 所要体现的服务宗旨所在。一个 web2.0 网站，博客也好、播客也好、点评也好，抑或是网摘、聚合门户，他们都强调人的参与性。物以类聚、人以群分，每个参与者都有自己的兴趣趋向，web2.0 网站的另一主要功能就是帮助这些人找到同样兴趣的人并形成一个活跃的群体，这是 web2.0 网站的根本。总结：web2.0 网站倡导的是集体创作、
9、共享资源，靠的是人气，体现的是参与性，一个没有参与性的 web2.0 网站都不足以成为web2.0。以上提到的这几个功能块就是以吸引用户参与和引导用户参与为目的的，真正的 web2.0 不是什么深奥的东西，只有一点，那就是如何让浏览者沸腾起来。二、 Flickr 的幕后故事我们都看到 Flickr 的成功，而又有多少“精英“们了解过 Flickr 背后的过程是多么充满艰险。Flickr 是全 CGI 的动态构架，并以一种 .gne 的脚本作为 CGI 程序语言。不管网站制作菜鸟还是高手都会疑惑：gne 是哪种程序语言？答案：gne 不是一种语言，Flickr 是以极为经典的 PHP + MyS
10、QL 方式实现的，在被 Yahoo 收购服务器搬入美国之前，使用了 21 台（69.90.111.101-121） Apache/PHP 做 Web、23 台图片服务器、另有 MySQL 服务器组成的数据库集群的服务器数量未知。现在估计使用的是 Yahoo 的负载均衡系统，对外只有一个 Web 的 IP 和图片服务器的 IP 了。那为何 .php 的文件要改成 .gne 呢？以往有大型网站为向后兼容性考虑，隐藏以程序语言命名的脚本文件扩展名，比如 Baidu 隐藏了 .php（Google 的 http 服务器是自己写的，整合了脚本程序，个别页面是 .py-Python） ；还有一些网站是改成
11、自己网站名相关的扩展名，如 MSN 的群组则是 .msnw，榕树下是 .rs。那 Flickr 的 gne 是什么意思？我在维基百科的 Flickr 条目上找到了答案(中文 Flickr 条目上没有写明) 。原来 GNE 是 Game NeverEnding 的缩写，Flickr 的开发者 Ludicorp 在 2002-2004 年一直在开发这套以 Game NerverEnding 为名称的大型多人在线角色扮演游戏-一套基于浏览器的 Web 游戏系统，个人以为应该就是当年九城的虚拟城市。但是开发近 3 年后该计划不得不破产，最终只发布了一个 Beta 版，而 Ludicorp 将这套系统稍
12、加移植，就有了 Flickr。呵呵，原来 gne 是一个项目的名称。关于 GNE 的一些连接：http:/del.icio.us/schee/gne。早期的 Flickr 想做成在类似聊天室的地方让网友分享、交流自己的照片，注重社区形式和保护照片不被外部引用（见徐子涵2004 年的文章） ，可能是看到了 Hello 的模式吧。但是聪明的 Flickr 团队不久就改变了策略，淡化了传统的社区形式-如聊天室、而加强了现在使其功成名就的 Tag 组织形式，一种更自由更随兴更轻松好玩的大社区形式，或者叫它广义社区吧，我随便叫的，可能太学究，看着别太在意就是了。另外，将原来照片只能在 Flash 内浏览
13、的限制区除了，并大力推荐用户将照片引用到自己的 Blog，这无疑对于挑战传统相册系统有决定性意义。减少 Flash 后的网页更多地引进了新兴的 Ajax 技术，使界面操作变得非常 Cool。这就是 Flickr 的历史，清晰地看到了他们对于优秀产品的执著。有了技术和经验积累，加上不断坚持，总有一天时来运转，你的产品会成为新潮流的里程碑。还有一句话要告诉 Yupoo 等：把 Flickr 想成一个有 Tag 功能的在线相册就已经错远了；复制粘贴者们想当然将 Flickr 去其糟粕取其精华，结果无关紧要的拿来了，将令人激动的优点都去掉了，结果剩下什么？三、 YouTube 的架构扩展在西雅图扩展性
14、的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)简单的说 YouTube 的数据流量, “一天的 YouTube 流量相当于发送 750 亿封电子邮件.“, 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,“每天有 10 亿次下载以及 6,5000 次上传“, 真假姑且不论, 的确是超乎寻常的海量. 国
15、内的互联网应用,但从数据量来看,怕是只有 有这个规模. 但技术上和 YouTube 就没法子比了.1. Web 服务器YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)2. 视频视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有 4 个缩略图，
16、而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 “迷你 Cluster“ 就是一组具有相同内容的服务器。最火的视频
17、放在 CDN 上，这样自己的服务器只需要承担一些“漏网“的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。3. 数据库YouTube 用 MySQL 存储元数据-用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展
18、性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是“分区“,这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)YouTube 也用 Memcached.很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?四、mixi.jp：使用开源软件搭建的可扩展 SNS 网站Mixi 目前是日本排名第三的网站，全球排名 42，主要提供 SNS服务：日记，群组，站内消息，评论，相册等等，是日本最大的SNS 网站。Mixi 从 2003 年 12 月份开始开发，由现在它的 CTO - Batara Kesuma 一个人焊，焊了
19、四个月，在 2004 年 2 月份开始上线运行。两个月后就注册了 1w 用户，日访问量 60wPV。在随后的一年里，用户增长到了 21w，第二年，增长到了 200w。到今年四月份已经增长到 370w 注册用户，并且还在以每天 1.5w 人的注册量增长。这些用户中 70%是活跃用户（活跃用户：三天内至少登录一次的用户） ，平均每个用户每周在线时间为将近 3 个半小时。下面我们来看它的技术架构。Mixi 采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid 等等。到目前为止已经有 100 多台 MySQL数据库服务器，并
20、且在以每月 10 多台的速度增长。Mixi 的数据库连接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以 InnoDB 方式运行。Mixi 解决扩展问题主要依赖于对数据库的切分。首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的 ID 将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户 ID 进去差不多就解决问题了，而以前如果 sq
21、l 代码到处飞，或者数据层封装的不太好的话那就累了。这样做了以后并不能从根本上解决问题，尤其是对于像 mixi 这种 SNS 网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached 的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知 cache 过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在 0.02 秒左右（当然根据页面大小情况不尽相似） ，可以说明这种做法是行之有效的。Mixi 一共在32 台机器上有缓存服务器，每个 Cac
22、he Server 2G 内存，这些Cache Server 与 App Server 装在一起。因为 Cache Server 对 CPU消耗不大，而有了 Cache Server 的支援，App Server 对内存要求也不是太高，所以可以和平共处，更有效的利用资源。图片的处理就显得相对简单的多了。对于 mixi 而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有 100 多 GB，它们被 Squid 和 CDN 所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用 Cache 不划算，所以对于这些照片
23、的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录，不然找不到放在哪台服务器上就郁闷了。五、 Technorati 的后台数据库架构Technorati (现在被阻尼了, 可能你访问不了)的 Dorion Carroll 在 2006 MySQL 用户会议上介绍了一些关于 Technorati 后台数据库架构的情况.基本情况目前处理着大约 10Tb 核心数据, 分布在大约 20 台机器上.通过复制, 多增加了 100Tb 数据, 分布在 200 台机器上. 每天增长的数据 1TB. 通过 SOA 的运用, 物理与逻辑的访问相
24、隔离, 似乎消除了数据库的瓶颈. 值得一提的是, 该扩展过程始终是利用普通的硬件与开源软件来完成的. 毕竟 , Web 2.0 站点都不是烧钱的主. 从数据量来看，这绝对是一个相对比较大的 Web 2.0 应用.Tag 是 Technorati 最为重要的数据元素. 爆炸性的 Tag 增长给 Technorati 带来了不小的挑战.2005 年 1 月的时候, 只有两台数据库服务器, 一主一从. 到了 06 年一月份, 已经是一主一从, 6 台 MyISAM 从数据库用来对付查询, 3 台 MyISAM 用作异步计算.一些核心的处理方法:1) 根据实体(tags/posttags)进行分区衡量
25、数据访问方法，读和写的平衡.然后通过不同的维度进行分区( Technorati 数据更新不会很多, 否则会成为数据库灾难)2) 合理利用 InnoDB 与 MyISAMInnoDB 用于数据完整性/写性能要求比较高的应用. MyISAM 适合进行 OLAP 运算. 物尽其用.3) MySQL 复制复制数据到从主数据库到辅数据库上,平衡分布查询与异步计算, 另外一个功能是提供冗余六、 通过了解 MySpace 的六次重构经历,来认识分布式系统到底该如何创建.在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修
26、订系统策略。虽然自 2005 年早期，站点账户数超过 7 百万后，系统架构到目前为止保持了相对稳定，但 MySpace 仍然在为 SQL Server 支持的同时连接数等方面继续攻坚，Benedetto 说， “我们已经尽可能把事情做到最好“。1. 里程碑一：50 万账户按 Benedetto 的说法，MySpace 最初的系统很小，只有两台Web 服务器和一个数据库服务器。那时使用的是 Dell 双 CPU、4G 内存的系统。单个数据库就意味着所有数据都存储在一个地方，再由两台Web 服务器分担处理用户请求的工作量。但就像 MySpace 后来的几次底层系统修订时的情况一样，三服务器架构很快
27、不堪重负。此后一个时期内，MySpace 基本是通过添置更多 Web 服务器来对付用户暴增问题的。但到在 2004 年早期，MySpace 用户数增长到 50 万后，数据库服务器也已开始汗流浃背。但和 Web 服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。在第二代架构中，MySpace 运行在 3 个 SQL Server 数据库服务器上-一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好-只要增加数据库服务器，加
28、大硬盘，就可以应对用户数和访问量的增加。2. 里程碑二：1-2 百万账户MySpace 注册数到达 1 百万至 2 百万区间后，数据库服务器开始受制于 I/O 容量-即它们存取数据的速度。而当时才是 2004 年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾“，Benedetto 说，这意味着 MySpace 永远都会轻度落后于用户需求。“有人花 5 分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。 “他补充道。这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是
29、，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace 将投入新的数据库予以支持它。账户到达 2 百万后，MySpace 还从存储设备与数据库服务器直接交互的方式切换到 SAN（Storage Area Network，存储区域网络）-用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性，Benedetto 说。3. 里程碑三：3 百万账户当用户继续增加到 3 百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须
30、共享。在这个架构里，每个数据库必须有各自的用户表副本-MySpace 授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在 9 个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。2004 年中，MySpace 面临 Web 开发者称之为“向上扩展“对“向外扩展“（译者注：Scale Up 和 Scale Out，也称硬件扩展和软件扩展）的抉择-要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的
31、服务器来分担数据库压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如 Google、Yahoo 和 A，都必须自行研发大量相关技术。以 Google 为例，它构建了自己的分布式文件系统。另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。 “搞不好，开发人员的所有工作都将白费“，Benedetto 说。因此，MySpace 首先将重点放在了向上扩展上，花费了大约 1个半月时间研究升级到 32CPU 服务器以管理更大数据库的问题。Benedetto 说， “那时候，
32、这个方案看似可能解决一切问题。 “如稳定性，更棒的是对现有软件几乎没有改动要求。糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto 说， “换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。 “因此，MySpace 最终将目光移到分布式计算架构-它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他
33、核心功能的数据都存储在相同数据库。既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace 必须找到新的办法以分担负荷-显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace 开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的 SQL Server 实例。目前，MySpace的每台数据库服务器实际运行两个 SQL Server 实例，也就是说每台服务器服务大约 2 百万用户。Benedetto 指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录
34、后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。4. 里程碑四：9 百万到 1 千 7 百万账户2005 年早期，账户达到 9 百万后，MySpace 开始用 Microsoft的 C#编写 ASP.NET 程序。C#是 C 语言的最新派生语言，吸收了 C+和 Java 的优点，依托于 Microsoft .NET 框架（Microsoft 为软件组件化和分布式计算而设计的模型架构） 。ASP.NET 则由编写 Web 站点脚本的 ASP 技术演化而来，是 Microsoft 目前主推的 Web 站点编程环境。可以
35、说是立竿见影， MySpace 马上就发现 ASP.NET 程序运行更有效率，与 ColdFusion 相比，完成同样任务需消耗的处理器能力更小。据技术总监 Whitcomb 说，新代码需要 150 台服务器完成的工作，如果用 ColdFusion 则需要 246 台。Benedetto 还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。最终，MySpace 开始大规模迁移到 ASP.NET。即便剩余的少部分ColdFusion 代码，也从 Cold-Fusion 服务器搬到了 ASP.NET，因为他们得到了 BlueDragon.N
36、ET（乔治亚州阿尔法利塔 New Atlanta Communications 公司的产品，它能将 ColdFusion 代码自动重新编译到 Microsoft 平台）的帮助。账户达到 1 千万时，MySpace 再次遭遇存储瓶颈问题。SAN 的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越 SAN 的 I/O 容量-即它从磁盘存储系统读写数据的极限速度。原因之一是每数据库 1 百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅 7 天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。某个数据库可能因为任何原因
37、，在任何时候遭遇主要负荷，这时，SAN 中绑定到该数据库的磁盘存储设备簇就可能过载。 “SAN 让磁盘 I/O 能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。 “Benedetto 说。最初，MySpace 通过定期重新分配 SAN 中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程， “大概需要两个人全职工作。 “Benedetto 说。长期解决方案是迁移到虚拟存储体系上，这样，整个 SAN 被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型 SAN 设备-来自加利福尼亚州弗里蒙特的3PARdata。在 3PAR 的系统里，仍能在
38、逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使 SAN 的任何组件过载。当 2005 年春天账户数达到 1 千 7 百万时，MySpace 又启用了新的策略以减轻存储系统压力，即增加数据缓存层-位于 Web 服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向 Web 应用供给数据。换句话说，100 个用户请求同一
39、份资料，以前需要查询数据库 100次，而现在只需 1 次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取-但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件-Benedetto 坦言他需要在这方面补课， “我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。 “但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。 “Benedetto 补充道。5. 里程
40、碑五：2 千 6 百万账户2005 年中期，服务账户数达到 2 千 6 百万时，MySpace 切换到了还处于 beta 测试的 SQL Server 2005。转换何太急？主流看法是2005 版支持 64 位处理器。但 Benedetto 说， “这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。 “支持 64 位的数据库可以管理更多内存。更多内存就意味着更高的性能和更大的容量。原来运行 32 位版本的 SQL Server 服务器，能同时使用的内存最多只有 4G。切换到64 位，就好像加粗了输水管的直径。升级到 SQL Server 2005 和 64位 Windows Ser
41、ver 2003 后，MySpace 每台服务器配备了 32G 内存，后于 2006 年再次将配置标准提升到 64G。意外错误如果没有对系统架构的历次修改与升级，MySpace 根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误“是怎么引起的呢？原因之一是 MySpace 对 Microsoft 的 Web 技术的应用已经进入连 Microsoft 自己也才刚刚开始探索的领域。比如 11 月，超出 SQL Server 最大同时连接数，MySpace 系统崩溃。Benedetto 说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致惹人恼怒。一旦
42、数据库罢工， “无论这种情况什么时候发生，未缓存的数据都不能从 SQL Server 获得，那么你就必然看到一个意外错误提示。 “他解释说。去年夏天，MySpace 的 Windows 2003 多次自动停止服务。后来发现是操作系统一个内置功能惹的祸-预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器瘫痪） 。MySpace 和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠 Windows 本身的功能来解决问题-否则，大量 MySpace 合法用户连接时也会引起服务器反击。“我们花了大约一个月时间寻找 Windows 2003 服务器自动停止
43、的原因。 “Benedetto 说。最后，通过 Microsoft 的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。 “紧接着是在去年 7 月某个周日晚上，MySpace 总部所在地洛杉矶停电，造成整个系统停运 12 小时。大型 Web 站点通常要在地理上分布配置多个数据中心以预防单点故障。本来，MySpace 还有其他两个数据中心以应对突发事件，但 Web 服务器都依赖于部署在洛杉矶的 SAN。没有洛杉矶的 SAN，Web 服务器除了恳求你耐心等待，不能提供任何服务。Benedetto 说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有 30 天燃料的
44、发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。2007 年中，MySpace 在另两个后备站点上也建设了 SAN。这对分担负荷大有帮助-正常情况下，每个 SAN 都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto 说。MySpace 仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。“作为开发人员，我憎恶 Bug，它太气人了。 “Dan Tanner 这个31 岁的德克萨斯软件工程师说，他通过 MySpace 重新联系到了高中和大学同学。 “不过，MySpace 对我们的
45、用处很大，因此我们可以原谅偶发的故障和错误。 “ Tanner 说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。这就是为什么 Drew 在论坛里咆哮时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew 无法平静，他写道， “我已经两次给 MySpace 发邮件，而它说一小时前还是正常的，现在出了点问题完全是一堆废话。 “另一个用户回复说，“毕竟它是免费的。 “Benedetto 坦承 100%的可靠性不是他的目标。“它不是银行，而是一个免费的服务。 “他说。换句话说，MySpace 的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户的
46、钱财。 “关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。“Benedetto 说。所以，MySpace 甘冒丢失 2 分钟到 2 小时内任意点数据的危险，在 SQL Server 配置里延长了“checkpoint“操作-它将待更新数据永久记录到磁盘-的间隔时间，因为这样做可以加快数据库的运行。Benedetto 说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入 Bug 的风险，但这样做可以更快实现新功能。而且，因为进行大规模真实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实
47、上不可能做真实的加载测试，他们做的测试通常都是针对站点。“我们犯过大量错误， “Benedetto 说， “但到头来，我认为我们做对的还是比做错的多。 “七、 从 LiveJournal 后台发展看大规模网站性能优化方法LiveJournal 是 99 年始于校园中的项目，几个人出于爱好做了这样一个应用，以实现以下功能：博客，论坛社会性网络，找到朋友聚合，把朋友的文章聚合在一起LiveJournal 采用了大量的开源软件，甚至它本身也是一个开源软件。在上线后，LiveJournal 实现了非常快速的增长：2004 年 4 月份：280 万注册用户。2005 年 4 月份：680 万注册用户。2
48、005 年 8 月份：790 万注册用户。达到了每秒钟上千次的页面请求及处理。使用了大量 MySQL 服务器。使用了大量通用组件。二、LiveJournal 架构现状概况三、从 LiveJournal 发展中学习LiveJournal 从 1 台服务器发展到 100 台服务器，这其中经历了无数的伤痛，但同时也摸索出了解决这些问题的方法，通过对LiveJournal 的学习，可以让我们避免 LJ 曾经犯过的错误，并且从一开始就对系统进行良好的设计，以避免后期的痛苦。下面我们一步一步看 LJ 发展的脚步。1、一台服务器一台别人捐助的服务器，LJ 最初就跑在上面，就像 Google 开始时候用的破服
49、务器一样，值得我们尊敬。这个阶段，LJ 的人以惊人的速度熟悉的 Unix 的操作管理，服务器性能出现过问题，不过还好，可以通过一些小修小改应付过去。在这个阶段里 LJ 把 CGI 升级到了 FastCGI。最终问题出现了，网站越来越慢，已经无法通过优过化来解决的地步，需要更多的服务器，这时 LJ 开始提供付费服务，可能是想通过这些钱来购买新的服务器，以解决当时的困境。毫无疑问，当时 LJ 存在巨大的单点问题，所有的东西都在那台服务器的铁皮盒子里装着。2、两台服务器用付费服务赚来的钱 LJ 买了两台服务器：一台叫做 Kenny 的Dell 6U 机器用于提供 Web 服务，一台叫做 Cartman 的 Dell 6U 服务器用于提供数据库服务。LJ 有了更大的磁盘，更多的计算资源。但同时网络结构还是非常简单，每台机器两块网卡，Cartman 通过内网为 Kenny 提供 MySQL数据库服务。暂时解决了负载的问题，新的问题又出现了：原来的一个单点变成了两个单点。没有冷备份或热备份。网站速度慢的问题又开始出现了，没办法，增长太快了。Web 服务器上 CPU 达到上限，需要更多的 Web 服务器。3、四台服务器又买了两台，Kyle 和 Stan，这次都是 1U 的，都用于提供 Web服务。目前 L
