闲谈 Web 图片服务器

  现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片,如果前期没有很好的规划,那么随着图片文件的增多,无论是管理还是性能上都带来很多问题。就自己的一点理解,抛砖引玉,以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备,那么简单的很;如果有能力自己开发单独存储图片的文件系统,那么也不用接着往下看了。
如果上述条件不具备,只想在普通的硬盘上存储,首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的,实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ,怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑,选择合适大小的 inode size ,在空间和速度上做取舍,同时防患于未然,注意单个文件系统下文件个数别达到极限。

独立,独立的服务器

无论从管理上,还是从性能上看,只要有可能,尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后,在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd
如果不想在几台机器间同步所有图片,只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题,以及 NFS 特定的传输速度。

独立,独立的域名

如果大部分 Web 页面必须要载入很多图片,那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。
前几天有个朋友在线上问我,”一些大网站,图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ,粗糙一点的答案:除了管理方便,便于CDN 同步处理,上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知,有请 Yahoo!的同学发言) 【还有一个我没考虑到的是 Cookie 的因素,参加楼下高春辉的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则,建议每个 Web 维护人员必须倒背如流,当然也应该辩证来看–介绍这 14 条规则的页面本身也只能得到 70 多分…其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache

很多网站的 UI 设计人员为了达到某些视觉效果,会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况,研究表明,对于用户粘度比较高的站点, 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的,大量带宽就这么节省下来,费用也节省了下来。顺便说一下,对于验证码这样的东西,要加个简单的规则过滤掉。

服务器端的 Cache

在国内,CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务,国内还没有出现。所以,充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器,缓冲图片效果应该说尚可,新浪技术团队贡献的 Ncache 据评测,效果更佳。

高解析图片问题

如果网站存在大量高解析度的图片,那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题

很多比较有规模的网站对于用户上传的图片不做任何处理,结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)…这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块,对那些”截屏”得来的图片做个转换,投入成本可能远比存储上的开销小,而用户再访问该图片,质量未必能有什么损失,浏览速度无疑好多了。哪种处理方式更让人接受,不言而喻。
FROM:

WEB2.0网站构架分析

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

如需转载,请注明:转载自老臧’s blog [ http://lovelaozang.cn/show-6781-1.html ]

关于大型网站构架的简要分析

      一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性能的要求都很简单,随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的。
 
       大型网站,比如门户网站。在面对大量用户访问、高并发请求方面,基本的解决方案集中在这样几个环节:使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面,还没法根本解决大型网站面临的高负载和高并发问题。
 
       上面提供的几个解决思路在一定程度上也意味着更大的投入,并且这样的解决思路具备瓶颈,没有很好的扩展性,下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。
 
1、HTML静态化
       其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。
       除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。
       同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现,比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。
 
2、图片服务器分离
       大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可能少的 LoadModule,保证更高的系统消耗和执行效率。
 
3、数据库集群和库表散列
       大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。
       在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。
       上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据
库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
 
4、缓存
       缓存一词搞技术的都接触过,很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
  架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。
  网站程序开发方面的缓存,Linux上提供的Memory Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大型社区使用了这样的架构。另外,在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多了,.net不是很熟悉,相信也肯定有。
 
5、镜像
       镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异,比如ChinaNet和 EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新。在镜像的细节技术方面,这里不阐述太深,有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路,比如Linux上的rsync等工具。
 
6、负载均衡
       负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
       负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,我个人接触过一些解决方法,其中有两个架构可以给大家做参考。
       硬件四层交换
       第四层交换使用第三层和第四层信息包的报头信息,根据应用区间识别业务流,将整个区间段的业务流分配到合适的应用服务器进行处理。 
第四层交换功能就象是虚 IP,指向物理服务器。它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器
基础上,需要复杂的载量平衡算法。在IP世界,业务类型由终端TCP或UDP端口地址来决定,在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
       在硬件四层交换产品领域,有一些知名的产品可以选择,比如Alteon、F5等,这些产品很昂贵,但是物有所值,能够提供非常优秀的性能和很
灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
 
7、软件四层交换

       大家知道了硬件四层交换机的原理后,基于OSI模型来实现的软件四层交换也就应运而生,这样的解决方案实现的原理一致,不过性能稍差。
但是满足一定量的压力还是游刃有余的,有人说软件实现方式其实更灵活,处理能力完全看你配置的熟悉能力。
       软件四层交换我们可以使用Linux上常用的LVS来解决,LVS就是Linux Virtual Server,他提供了基于心跳线heartbeat的实时灾难应对解决方案,提高系统的鲁棒性,同时可供了灵活的虚拟VIP配置和管理功能,可以同时满足多种应用需求,这对于分布式的系统来说必不可少。
 
       一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。
 
       对于大型网站来说,前面提到的每个方法可能都会被同时使用到,我这里介绍得比较浅显,具体实现过程中很多细节还需要大家慢慢熟悉和体会,有时一个很小的 squid参数或者apache参数设置,对于系统性能的影响就会很大,希望大家一起讨论,达到抛砖引玉之效。
FROM:51CTO

亿万用户网站MySpace网站架构及成功秘密

《亿万用户网站MySpace的成功秘密》 ◎ 文 / David F. Carr   译 / 罗小平
     增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统,以期与自身的成长同步——目前,该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分,但那些指望迈入庞大在线市场的人,可以从MySpace的成长过程学到知识。
用户的烦恼
     Drew,是个来自达拉斯的17岁小伙子,在他的MySpace个人资料页上,可以看到他的袒胸照,看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接,另外还说自己参加了学校田径队,爱好吉他,开一辆蓝色福特野马。
     不过在用户反映问题的论坛里,似乎他的火气很大。“赶紧弄好这该死的收件箱!”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息,但当他要查看一条消息时,页面却出现提示:“非常抱歉……消息错误”。
     Drew的抱怨说明1.4亿用户非常重视在线交流系统,这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。
     11月,MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示,MySpace当月访问量为387亿,而Yahoo是380.5亿。
     显然,MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。事实上,MySpace的Web服务器和数据库经常性超负荷,其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的 MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务,他们不得不在论坛抱怨不停。
     尤其是最近,MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说,“难以想象,在有些时候,我们发现20%的错误日志都来自MySpace,有时候甚至达到30%以至40%……而Yahoo、 Salesforce.com和其他提供商用服务的站点,从来不会出现这样的数字。”他告诉我们,其他大型站点的日错误率一般就1%多点。
    顺便提及,MySpace在2006年7月24号晚上开始了长达12小时的瘫痪,期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发生故障。为了让大家耐心等待服务恢复,该页面提供了用Flash开发的派克人(Pac-Man)游戏。Web站点跟踪服务研究公司总经理Bill Tancer说,尤其有趣的是,MySpace瘫痪期间,访问量不降反升,“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。现 Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师,因在Web站点方面的评论而闻名的Jakob Nielsen说,MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样,他相信MySpace对其成长速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新,但他们面对的的确是一个巨大的科学难题。”他说。
     MySpace开发人员已经多次重构站点软件、数据库和存储系统,以满足爆炸性的成长需要,但此工作永不会停息。“就像粉刷金门大桥,工作完成之时,就是重新来过之日。”(译者注:意指工人从桥头开始粉刷,当到达桥尾时,桥头涂料已经剥落,必须重新开始)MySpace技术副总裁Jim Benedetto说。既然如此,MySpace的技术还有何可学之处?因为MySpace事实上已经解决了很多系统扩展性问题,才能走到今天。
     Benedetto说他的项目组有很多教训必须总结,他们仍在学习,路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统,以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。
背景知识


MySpace logo
MySpace logo

    MySpace目前的努力方向是解决扩展性问题,但其领导人最初关注的是系统性能。
3年多前,一家叫做Intermix Media(早先叫eUniverse。这家公司从事各类电子邮件营销和网上商务)的公司推出了MySpace。而其创建人是Chris DeWolfe和Tom Anderson,他们原来也有一家叫做ResponseBase的电子邮件营销公司,后于2002年出售给Intermix。据Brad Greenspan(Intermix前CEO)运作的一个网站披露,ResponseBase团队为此获得2百万美金外加分红。Intermix是一家颇具侵略性的互联网商务公司——部分做法可能有点过头。2005年,纽约总检察长Eliot Spitzer——现在是纽约州长——起诉Intermix使用恶意广告软件推广业务,Intermix最后以790万美元的代价达成和解。
     2003年,美国国会通过《反垃圾邮件法》(CAN-SPAM Act),意在控制滥发邮件的营销行为。Intermix领导人DeWolfe和Anderson意识到新法案将严重打击公司的电子邮件营销业务,“因此必须寻找新的方向。”受聘于Intermix负责重写公司邮件营销软件的Duc Chau说。
     当时有个叫Friendster的交友网站,Anderson和DeWolfe很早就是它的会员。于是他们决定创建自己的网上社区。他们去除了 Friendster在用户自我表述方面的诸多限制,并重点突出音乐(尤其是重金属乐),希望以此吸引用户。Chau使用Perl开发了最初的 MySpace版本,运行于Apache Web服务器,后台使用MySQL数据库。但它没有通过终审,因为Intermix的多数开发人员对ColdFusion(一个Web应用程序环境,最初由Allaire开发,现为Adobe所有)更为熟悉。因此,最后发布的产品采用ColdFusion开发,运行在Windows上,并使用MS SQL Server作为数据库服务器。
     Chau就在那时离开了公司,将开发工作交给其他人,包括Aber Whitcomb(Intermix的技术专家,现在是MySpace技术总监)和Benedetto(MySpace现技术副总裁,大概于MySpace上线一个月后加入)。
     MySpace上线的2003年,恰恰是Friendster在满足日益增长的用户需求问题上遭遇麻烦的时期。财富杂志最近的一次采访中,Friendster总裁Kent Lindstrom承认他们的服务出现问题选错了时候。那时,Friendster传输一个页面需要20到30秒,而MySpace只需2到3秒。结果,Friendster用户开始转投MySpace,他们认为后者更为可靠。
     今天,MySpace无疑已是社区网站之王。社区网站是指那些帮助用户彼此保持联系、通过介绍或搜索、基于共同爱好或教育经历交友的Web站点。在这个领域比较有名的还有最初面向大学生的Facebook、侧重职业交流的LinkedIn,当然还少不了Friendster。MySpace宣称自己是“下一代门户”,强调内容的丰富多彩(如音乐、趣事和视频等)。其运作方式颇似一个虚拟的夜总会——为未成年人在边上安排一个果汁吧,而显著位置则是以性为目的的约会,和寻找刺激派对气氛的年轻人的搜索服务。
     用户注册时,需要提供个人基本信息,主要包括籍贯、性取向和婚姻状况。虽然MySpace屡遭批评,指其为网上性犯罪提供了温床,但对于未成年人,有些功能还是不予提供的。
  MySpace的个人资料页上表述自己的方式很多,如文本式“关于本人”栏、选择加载入MySpace音乐播放器的歌曲,以及视频、交友要求等。它还允许用户使用CSS(一种Web标准格式语言,用户以此可设置页面元素的字体、颜色和页面背景图像)自由设计个人页面,这也提升了人气。不过结果是五花八门 ——很多用户的页面布局粗野、颜色迷乱,进去后找不到东南西北,不忍卒读;而有些人则使用了专业设计的模版(可阅读《Too Much of a Good Thing?》第49页),页面效果很好。
     在网站上线8个月后,开始有大量用户邀请朋友注册MySpace,因此用户量大增。“这就是网络的力量,这种趋势一直没有停止。”Chau说。
     拥有Fox电视网络和20th Century Fox影业公司的媒体帝国——新闻集团,看到了他们在互联网用户中的机会,于是在2005年斥资5.8亿美元收购了MySpace。新闻集团董事局主席 Rupert Murdoch最近向一个投资团透露,他认为MySpace目前是世界主要Web门户之一,如果现在出售MySpace,那么可获60亿美元——这比 2005年收购价格的10倍还多!新闻集团还惊人地宣称,MySpace在2006年7月结束的财政年度里总收入约2亿美元,而且预期在2007年度,Fox Interactive公司总收入将达到5亿美元,其中4亿来自MySpace。
  然而MySpace还在继续成长。12月份,它的注册账户达到1.4亿,而2005年11月时不过4千万。当然,这个数字并不等于真实的用户个体数,因为有些人可能有多个帐号,而且个人资料也表明有些是乐队,或者是虚构的名字,如波拉特(译者注:喜剧电影《Borat》主角),还有像Burger King(译者注:美国最大的汉堡连锁集团)这样的品牌名。
     当然,这么多的用户不停发布消息、撰写评论或者更新个人资料,甚至一些人整天都泡在Space上,必然给MySpace的技术工作带来前所未有的挑战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费,它们的内容数据库通常可以优化为只读模式,因为用户评论等引起的增加和更新操作很少。而MySpace是由用户提供内容,数据库很大比例的操作都是插入和更新,而非读取。
  浏览MySpace上的任何个人资料时,系统都必须先查询数据库,然后动态创建页面。当然,通过数据缓存,可以减轻数据库的压力,但这种方案必须解决原始数据被用户频繁更新带来的同步问题。
     MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后,必须做大量的调整和优化。Benedetto说,“但我们始终跟不上形势的发展速度。我们重构重构再重构,一步步挪到今天”。
  尽管MySpace拒绝了正式采访,但Benedetto在参加11月于拉斯维加斯召开的SQL Server Connections会议时还是回答了Baseline的问题。本文的不少技术信息还来源于另一次重要会议——Benedetto和他的老板——技术总监Whitcomb今年3月出席的Microsoft MIX Web开发者大会。
  据他们讲,MySpace很多大的架构变动都发生在2004和2005年早期——用户数在当时从几十万迅速攀升到了几百万。
     在每个里程碑,站点负担都会超过底层系统部分组件的最大载荷,特别是数据库和存储系统。接着,功能出现问题,用户失声尖叫。最后,技术团队必须为此修订系统策略。
  虽然自2005年早期,站点账户数超过7百万后,系统架构到目前为止保持了相对稳定,但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚,Benedetto说,“我们已经尽可能把事情做到最好”。
 
里程碑一:50万账户
     按Benedetto 的说法,MySpace最初的系统很小,只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。
  单个数据库就意味着所有数据都存储在一个地方,再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样,三服务器架构很快不堪重负。此后一个时期内,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
  但到在2004年早期,MySpace用户数增长到50万后,数据库服务器也已开始汗流浃背。
  但和Web服务器不同,增加数据库可没那么简单。如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下,让多个数据库分担压力。
  在第二代架构中,MySpace运行在3个SQL Server数据库服务器上——一个为主,所有的新数据都向它提交,然后由它复制到其他两个;另两个全力向用户供给数据,用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。
里程碑二:1-2百万账户
     MySpace注册数到达1百万至2百万区间后,数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中,距离上次数据库系统调整不过数月。用户的提交请求被阻塞,就像千人乐迷要挤进只能容纳几百人的夜总会,站点开始遭遇“主要矛盾”,Benedetto说,这意味着 MySpace永远都会轻度落后于用户需求。“有人花5分钟都无法完成留言,因此用户总是抱怨说网站已经完蛋了。”他补充道。
  这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。于是,站点的扩展性问题看似又可以告一段落了,可以歇一阵子。
  垂直分割策略利于多个数据库分担访问压力,当用户要求增加新功能时,MySpace将投入新的数据库予以支持它。账户到达2百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN(Storage Area Network,存储区域网络)——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性,Benedetto说。
里程碑三:3百万账户
     当用户继续增加到3百万后,垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立,但有些信息必须共享。在这个架构里,每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时,该条账户记录必须在9个不同数据库上分别创建。但在个别情况下,如果其中某台数据库服务器临时不可到达,对应事务就会失败,从而造成账户非完全创建,最终导致此用户的该项服务无效。
  另外一个问题是,个别应用如博客增长太快,那么专门为它服务的数据库就有巨大压力。
  2004年中,MySpace面临Web开发者称之为“向上扩展”对“向外扩展”(译者注:Scale Up和Scale Out,也称硬件扩展和软件扩展)的抉择——要么扩展到更大更强、也更昂贵的服务器上,要么部署大量相对便宜的服务器来分担数据库压力。一般来说,大型站点倾向于向外扩展,因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
  但成功地向外扩展架构必须解决复杂的分布式计算问题,大型站点如Google、Yahoo和Amazon.com,都必须自行研发大量相关技术。以Google为例,它构建了自己的分布式文件系统。
     另外,向外扩展策略还需要大量重写原来软件,以保证系统能在分布式服务器上运行。“搞不好,开发人员的所有工作都将白费”,Benedetto说。因此,MySpace首先将重点放在了向上扩展上,花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说,“那时候,这个方案看似可能解决一切问题。”如稳定性,更棒的是对现有软件几乎没有改动要求。糟糕的是,高端服务器极其昂贵,是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且,站点架构师预测,从长期来看,即便是巨型数据库,最后也会不堪重负,Benedetto说,“换句话讲,只要增长趋势存在,我们最后无论如何都要走上向外扩展的道路。”
     因此,MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。拿数据库来说,就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
     既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力的。这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server实例。目前,MySpace的每台数据库服务器实际运两个SQL Server实例,也就是说每台服务器服务大约2百万用户。Benedetto指出,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。
  当然,还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后,保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大,但它只负责用户登录,功能单一,所以负荷还是比较容易控制的。
里程碑四:9百万到1千7百万账户
     2005年早期,账户达到9百万后,MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言,吸收了C++和 Java的优点,依托于Microsoft .NET框架(Microsoft为软件组件化和分布式计算而设计的模型架构)。ASP.NET则由编写Web站点脚本的ASP技术演化而来,是 Microsoft目前主推的Web站点编程环境。
  可以说是立竿见影,MySpace马上就发现ASP.NET程序运行更有效率,与ColdFusion相比,完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说,新代码需要150台服务器完成的工作,如果用ColdFusion则需要246台。Benedetto还指出,性能上升的另一个原因可能是在变换软件平台,并用新语言重写代码的过程中,程序员复审并优化了一些功能流程。
      最终,MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码,也从Cold-Fusion服务器搬到了 ASP.NET,因为他们得到了BlueDragon.NET(乔治亚州阿尔法利塔New Atlanta Communications公司的产品,它能将ColdFusion代码自动重新编译到Microsoft平台)的帮助。
     账户达到1千万时,MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
     原因之一是每数据库1百万账户的分割策略,通常情况下的确可以将压力均分到各台服务器,但现实并非一成不变。比如第七台账户数据库上线后,仅仅7天就被塞满了,主要原因是佛罗里达一个乐队的歌迷疯狂注册。
     某个数据库可能因为任何原因,在任何时候遭遇主要负荷,这时,SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了,但将它们绑定到特定数据库的做法是错误的。”Benedetto说。
     最初,MySpace通过定期重新分配SAN中数据,以让其更为均衡的方法基本解决了这个问题,但这是一个人工过程,“大概需要两个人全职工作。”Benedetto说。
  长期解决方案是迁移到虚拟存储体系上,这样,整个SAN被当作一个巨型存储池,不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
     在3PAR的系统里,仍能在逻辑上按容量划分数据存储,但它不再被绑定到特定磁盘或磁盘簇,而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时,任何空闲磁盘都可以马上完成这项工作,而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且,因为多个磁盘都有数据副本,读取数据时,也不会使SAN的任何组件过载。
  当2005年春天账户数达到1千7百万时,MySpace又启用了新的策略以减轻存储系统压力,即增加数据缓存层——位于Web服务器和数据库服务器之间,其唯一职能是在内存中建立被频繁请求数据对象的副本,如此一来,不访问数据库也可以向Web应用供给数据。换句话说,100个用户请求同一份资料,以前需要查询数据库100次,而现在只需1次,其余都可从缓存数据中获得。当然如果页面变化,缓存的数据必须从内存擦除,然后重新从数据库获取——但在此之前,数据库的压力已经大大减轻,整个站点的性能得到提升。
     缓存区还为那些不需要记入数据库的数据提供了驿站,比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课,“我是数据库存储狂热分子,因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库,站点将陷入泥沼。
  增加缓存服务器是“一开始就应该做的事情,但我们成长太快,以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。
里程碑五:2千6百万账户
     2005年中期,服务账户数达到2千6百万时,MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急?主流看法是2005版支持64位处理器。但Benedetto说,“这不是主要原因,尽管这也很重要;主要还是因为我们对内存的渴求。”支持64位的数据库可以管理更多内存。
     更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器,能同时使用的内存最多只有4G。切换到64位,就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后,MySpace每台服务器配备了32G内存,后于2006年再次将配置标准提升到64G。
意外错误
     如果没有对系统架构的历次修改与升级,MySpace根本不可能走到今天。但是,为什么系统还经常吃撑着了?很多用户抱怨的“意外错误”是怎么引起的呢?
  原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月,超出SQL Server最大同时连接数,MySpace系统崩溃。Benedetto说,这类可能引发系统崩溃的情况大概三天才会出现一次,但仍然过于频繁了,以致惹人恼怒。一旦数据库罢工,“无论这种情况什么时候发生,未缓存的数据都不能从SQL Server获得,那么你就必然看到一个‘意外错误’提示。”他解释说。
  去年夏天,MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击(黑客使用很多客户机向服务器发起大量连接请求,以致服务器瘫痪)。MySpace和其他很多顶级大站点一样,肯定会经常遭受攻击,但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则,大量 MySpace合法用户连接时也会引起服务器反击。
    “我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后,通过Microsoft的帮助,他们才知道该怎么通知服务器:“别开枪,是友军。”
  紧接着是在去年7月某个周日晚上,MySpace总部所在地洛杉矶停电,造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来,MySpace还有其他两个数据中心以应对突发事件,但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN,Web服务器除了恳求你耐心等待,不能提供任何服务。
     Benedetto说,主数据中心的可靠性通过下列措施保证:可接入两张不同电网,另有后备电源和一台储备有30天燃料的发电机。但在这次事故中,不仅两张电网失效,而且在切换到备份电源的过程中,操作员烧掉了主动力线路。
     2007年中,MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下,每个SAN都能负担三分之一的数据访问量。而在紧急情况下,任何一个站点都可以独立支撑整个服务,Benedetto说。
       MySpace仍然在为提高稳定性奋斗,虽然很多用户表示了足够信任且能原谅偶现的错误页面。“作为开发人员,我憎恶Bug,它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说,他通过MySpace重新联系到了高中和大学同学。“不过,MySpace对我们的用处很大,因此我们可以原谅偶发的故障和错误。” Tanner说,如果站点某天出现故障甚至崩溃,恢复以后他还是会继续使用。
     这就是为什么Drew在论坛里咆哮时,大部分用户都告诉他应该保持平静,如果等几分钟,问题就会解决的原因。Drew无法平静,他写道,“我已经两次给 MySpace发邮件,而它说一小时前还是正常的,现在出了点问题……完全是一堆废话。”另一个用户回复说,“毕竟它是免费的。”Benedetto坦承 100%的可靠性不是他的目标。“它不是银行,而是一个免费的服务。”他说。
     换句话说,MySpace的偶发故障可能造成某人最后更新的个人资料丢失,但并不意味着网站弄丢了用户的钱财。“关键是要认识到,与保证站点性能相比,丢失少许数据的故障是可接受的。”Benedetto说。所以,MySpace甘冒丢失2分钟到2小时内任意点数据的危险,在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间,因为这样做可以加快数据库的运行。
     Benedetto说,同样,开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险,但这样做可以更快实现新功能。而且,因为进行大规模真实测试不具可行性,他们的测试通常是在仅以部分活跃用户为对象,且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试,他们做的测试通常都是针对站点。
   “我们犯过大量错误,”Benedetto说,“但到头来,我认为我们做对的还是比做错的多。”

YouTube架构分析

YouTube的成长速度惊人,目前每天视频访问量已达1亿,但站点维护人员很少。他们是如何管理,以实现如此强大供应能力的?被Google收购后,又在走什么样的发展道路呢?
大小: 1.44 K 尺寸: 80 x 30 浏览: 0 次 点击打开新窗口浏览全图
转载一些相关的文章,参考学习一下
原文: YouTube Architecture
YouTube发展迅速,每天超过1亿的视频点击量,但只有很少人在维护站点和确保伸缩性。
平台
Apache
Python
Linux(SuSe)
MySQL
psyco,一个动态的Python到C的编译器
lighttpd代替Apache做视频查看
状态
支持每天超过1亿的视频点击量
成立于2005年2月
于2006年3月达到每天3千万的视频点击量
于2006年7月达到每天1亿的视频点击量
2个系统管理员,2个伸缩性软件架构师
2个软件开发工程师,2个网络工程师,1个DBA
处理飞速增长的流量

Java代码 
  1. while (true)  
  2. {  
  3.   identify_and_fix_bottlenecks();  
  4.   drink();  
  5.   sleep();  
  6.   notice_new_bottleneck();  
  7. }  

每天运行该循环多次
Web服务器
1,NetScaler用于负载均衡和静态内容缓存
2,使用mod_fast_cgi运行Apache
3,使用一个Python应用服务器来处理请求的路由
4,应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面
5,一般可以通过添加更多的机器来在Web层提高伸缩性
6,Python的Web层代码通常不是性能瓶颈,大部分时间阻塞在RPC
7,Python允许快速而灵活的开发和部署
8,通常每个页面服务少于100毫秒的时间
9,使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环
10,对于像加密等密集型CPU活动,使用C扩展
11,对于一些开销昂贵的块使用预先生成并缓存的html
12,数据库里使用行级缓存
13,缓存完整的Python对象
14,有些数据被计算出来并发送给各个程序,所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改,预计算,然后发送。
视频服务
1,花费包括带宽,硬件和能源消耗
2,每个视频由一个迷你集群来host,每个视频被超过一台机器持有
3,使用一个集群意味着:
-更多的硬盘来持有内容意味着更快的速度
-failover。如果一台机器出故障了,另外的机器可以继续服务
-在线备份
4,使用lighttpd作为Web服务器来提供视频服务:
-Apache开销太大
-使用epoll来等待多个fds
-从单进程配置转变为多进程配置来处理更多的连接
5,大部分流行的内容移到CDN:
-CDN在多个地方备份内容,这样内容离用户更近的机会就会更高
-CDN机器经常内存不足,因为内容太流行以致很少有内容进出内存的颠簸
6,不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器
-长尾效应。一个视频可以有多个播放,但是许多视频正在播放。随机硬盘块被访问
-在这种情况下缓存不会很好,所以花钱在更多的缓存上可能没太大意义。
-调节RAID控制并注意其他低级问题
-调节每台机器上的内存,不要太多也不要太少
视频服务关键点
1,保持简单和廉价
2,保持简单网络路径,在内容和用户间不要有太多设备
3,使用常用硬件,昂贵的硬件很难找到帮助文档
4,使用简单而常见的工具,使用构建在Linux里或之上的大部分工具
5,很好的处理随机查找(SATA,tweaks)
缩略图服务
1,做到高效令人惊奇的难
2,每个视频大概4张缩略图,所以缩略图比视频多很多
3,缩略图仅仅host在几个机器上
4,持有一些小东西所遇到的问题:
-OS级别的大量的硬盘查找和inode和页面缓存问题
-单目录文件限制,特别是Ext3,后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录,但在一个文件系统里存储大量文件不是个好主意
-每秒大量的请求,因为Web页面可能在页面上显示60个缩略图
-在这种高负载下Apache表现的非常糟糕
-在Apache前端使用squid,这种方式工作了一段时间,但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个
-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题,因为它们各自保持自己单独的缓存
-如此多的图片以致一台新机器只能接管24小时
-重启机器需要6-10小时来缓存
5,为了解决所有这些问题YouTube开始使用Google的BigTable,一个分布式数据存储:
-避免小文件问题,因为它将文件收集到一起
-快,错误容忍
-更低的延迟,因为它使用分布式多级缓存,该缓存与多个不同collocation站点工作
-更多信息参考Google ArchitectureGoogleTalk ArchitectureBigTable
还有从DBA Notes看到过的一些:

一、系统主要用Python开发,用psyco提高性能

看到这个我总算知道Google为什么要收购YouTube了,都喜欢用Python嘛,本 来就有缘。用Python开发的速度显然比用C/C++、 Java等高不少,这一点eBay就比较传统,用C++/Java来写,结果落得需要几百个工程师,编译一次很久。最感兴趣的是用了psyco这个东西,所说这玩意相当于Java中的JIT编译器,通常能将Python代码的执行速度提高4倍,对于算法集中的代码甚至能提高10到100倍。

二、使用lighttpd

给视频内容本身提供服务时用了lighttpd,不能Apache,据说性能提高不少,但有了说这个还不好,应该用nginx,俄罗斯人写的一玩意。

三、最流行的内容自己不管,放在CDN上

YouTube很会享受,最常访问的内容自己的系统不管,放在运营商和Google(估计是被Google收购之后吧?)的内容分发网络上。他们自己的服务器只要处理一些不常访问的漏网之鱼就可以了,负载大大减轻。

四、缩略图是最大的问题,自己搞不定,最后用Google的BigTable搞定

俗话说人小鬼大绝对是有道理的,那么大的视频没什么问题,小小的缩略图却是个大问题。原来YouTube的开发人员用lighttpd,发现效果不太好,就改了代码,但效果还是不行。最后被Google收购后用了BigTable才算搞定这个问题。

五、MySQL swap问题,把swap关掉就行了

YouTube用MySQL存元数据,结果在Linux上swap颠簸很厉害,解决的方法也简单,把swap关掉就好了。而且人家胆子大,服务还在那里跑,这边就把它关了。

六、MySQL

YouTube 用MySQL也是摸着石头过河,一开始只用一个主服务器和replication,显然过一阵子这个方法就不行了。后面他们尝试把视频和非视频业务分开处 理,但这个方法也顶不了多久。最终还是走到数据分区这条正道上来。对数据库服务器的磁盘系统的选择也很有意思,最早是用10块盘做RAID 1+0,但发现盘太多了也使不上劲,所以后来改后一堆RAID 1。