现在的位置: 首页 > 综合 > 正文

知名网站架构(一)

2018年05月04日 ⁄ 综合 ⁄ 共 29838字 ⁄ 字号 评论关闭
文章目录

 

mixi.jp:使用开源软件搭建的可扩展SNS网站 

 http://www.w2blog.net/view/229.html

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不划算,所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上,在用户访问的时候直接进行访问,当然图片的位置需要在数据库中进行记录,不然找不到放在哪台服务器上就郁闷了。

 

 http://www.example.net.cn/2006/06/feedburnermysqljavaweb.html

FeedBurner:基于MySQL和JAVA的可扩展Web应用
于敦德 2006-6-27

FeedBurner(以下简称FB,呵呵)我想应该是大家耳熟能详的一个名字,在国内我们有一个同样的服务商,叫做FeedSky。在2004年7月份,FB的流量是300kbps,托管是5600个源,到2005年4月份,流量已经增长到5Mbps,托管了47700个源;到2005年9月份流量增长到20M,托管了109200个源,而到2006年4月份,流量已经到了115Mbps,270000个源,每天点击量一亿次。

FB的服务使用Java实现,使用了Mysql数据库。我们下面来看一下FB在发展的过程中碰到的问题,以及解决的方案。

在2004年8月份,FB的硬件设备包括3台Web服务器,3台应用服务器和两台数据库服务器,使用DNS轮循分布服务负载,将前端请求分布到三台Web服务器上。说实话,如果不考虑稳定性,给5600个源提供服务应该用不了这么多服务器。现在的问题是即使用了这么多服务器他们还是无法避免单点问题,单点问题将至少影响到1/3的用户。FB采用了监控的办法来解决,当监控到有问题出现时及时重启来避免更多用户受到影响。FB采用了Cacti(http://www.cacti.net)和Nagios(http://www.nagios.org)来做监控。

FB碰到的第二个问题是访问统计和管理。可以想象,每当我们在RSS阅读器里点击FB发布的内容,都需要做实时的统计,这个工作量是多么的巨大。大量写操作将导致系统的效率急剧下降,如果是Myisam表的话还会导致表的死锁。FB一方面采用异步写入机制,通过创建执行池来缓冲写操作;只对本日的数据进行实时统计,而以前的数据以统计结果形式存储,进而避免每次查看访问统计时的重复计算。所以每一天第一次访问统计信息时速度可能会慢,这个时候应该是FB在分析整理前一天的数据,而接下来的访问由于只针对当日数据进行分析,数据量小很多,当然也会快很多。FB的Presentation是这样写,但我发现好像我的FB里并没有今天实时的统计,也许是我观察的不够仔细-_-!

现在第三个问题出现了,由于大多数的操作都集中在主数据库上,数据库服务器的读写出现了冲突,前面提到过Myiasm类型的数据库在写入的时候会锁表,这样就导致了读写的冲突。在开始的时候由于读写操作比较少这个问题可能并不明显,但现在已经到了不能忽视的程度。解决方案是平衡读写的负载,以及扩展HibernateDaoSupport,区分只读与读写操作,以实现针对读写操作的不同处理。

现在是第四个问题:数据库全面负载过高。由于使用数据库做为缓存,同时数据库被所有的应用服务器共享,速度越来越慢,而这时数据库大小也到了Myisam的上限-4GB,FB的同学们自己都觉得自己有点懒。解决方案是使用内存做缓存,而非数据库,他们同样使用了我们前面推荐的memcached,同时他们还使用了Ehcache(http://ehcache.sourceforge.net/),一款基于Java的分布式缓存工具。

第五个问题:流行rss源带来大量重复请求,导致系统待处理请求的堆积。同时我们注意到在RSS源小图标有时候会显示有多少用户订阅了这一RSS源,这同样需要服务器去处理,而目前所有的订阅数都在同一时间进行计算,导致对系统资源的大量占用。解决方案,把计算时间错开,同时在晚间处理堆积下来的请求,但这仍然不够。

问题六:状态统计写入数据库又一次出问题了。越来越多的辅助数据(包括广告统计,文章点击统计,订阅统计)需要写入数据库,导致太多的写操作。解决方案:每天晚上处理完堆积下来的请求后对子表进行截断操作:

– FLUSH TABLES; TRUNCATE TABLE ad_stats0;

这样的操作对Master数据库是成功的,但对Slave会失败,正确的截断子表方法是:

– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2);

– TRUNCATE TABLE ad_stats0;

– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2);

解决方案的另外一部分就是我们最常用的水平分割数据库。把最常用的表分出去,单独做集群,例如广告啊,订阅计算啊,

第七个问题,问题还真多,主数据库服务器的单点问题。虽然采用了Master-Slave模式,但主数据库Master和Slave都只有一台,当Master出问题的时候需要太长的时间进行Myisam的修复,而Slave又无法很快的切换成为Master。FB试了好多办法,最终的解决方案好像也不是非常完美。从他们的实验过程来看,并没有试验Master-Master的结构,我想Live Journal的Master-Master方案对他们来说应该有用,当然要实现Master-Master需要改应用,还有有些麻烦的。

第八个问题,停电!芝加哥地区的供电状况看来不是很好,不过不管好不好,做好备份是最重要的,大家各显神通吧。

这个Presentation好像比较偏重数据库,当然了,谁让这是在Mysql Con上的发言,不过总给人一种不过瘾的感觉。另外一个感觉,FB的NO们一直在救火,没有做系统的分析和设计。

最后FB的运维总监Joe Kottke给了四点建议:

1、 监控网站数据库负载。

2、 “explain”所有的SQL语句。

3、 缓存所有能缓存的东西。

4、 归档好代码。

最后,FB用到的软件都不是最新的,够用就好,包括:Tomcat5.0,Mysql 4.1,Hibernate 2.1,Spring,DBCP。

文章参考了Joe Kottke在MySQL Users Conference 2006上的发言。

 

YouTube 的架构扩展
http://www.dbanotes.net/opensource/youtube_web_arch.html

作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/opensource/youtube_web_arch.html
在西雅图扩展性的技术研讨会上,YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址),可惜国内用户看不到。

Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)

简单的说 YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.

Web 服务器
YouTube 出于开发速度的考虑,大部分代码都是 Python 开发的。Web 服务器有部分是 Apache, 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知,MySpace 也有部分服务器用 Lighttpd ,但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多,豆瓣用的比较舒服。by Fenng)

视频
视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图,而每个 Web 页面上更是有多个,每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力,并且针对 Cache 和 OS 做了部分优化。另一方面,缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable, 这下子从性能、容错、缓存上都有更好表现。看人家这收购的,好钢用在了刀刃上。

出于冗余的考虑,每个视频文件放在一组迷你 Cluster 上,所谓 "迷你 Cluster" 就是一组具有相同内容的服务器。最火的视频放在 CDN 上,这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件,这一点和 Google 风格倒是一致。至于维护手段,也都是常见的工具,如 rsync, SSH 等,只不过人家更手熟罢了。

数据库
YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题,解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘,RAID 10 ,后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面,路线也是和其他站点类似,复制,分散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区,而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

YouTube 也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

--EOF--

这篇 【YouTube 的架构扩展 】来自 dbanotes.net |  del.icio.us 收藏
By Fenng on July 24, 2007 6:53 PM | Twitter | Comments (27) | OpenSource | Edit

Generator | Trampoline

 

YouTube Scalability视频 Google Video在线代理地址
国内的朋友可以直接点击观看
http://www.instantmastercard.info/index.php?q=aHR0cDovL3ZpZGVvLmdvb2dsZS5jb20vdmlkZW9wbGF5P2RvY2lkPS02MzA0OTY0MzUxNDQxMzI4NTU5

 

了解一下 Technorati 的后台数据库架构

http://www.dbanotes.net/web/technorati_db_arch.html

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 复制
复制数据到从主数据库到辅数据库上,平衡分布查询与异步计算, 另外一个功能是提供冗余. 如图:

 

后记
拜读了一个藏袍的两篇大做(mixi.jp:使用开源软件搭建的可扩展SNS网站 / FeedBurner:基于MySQL和JAVA的可扩展Web应用) 心痒难当, 顺藤摸瓜, 发现也有文档提及 Technorati , 赶紧照样学习一下. 几篇文档读罢, MySQL 的 可扩展性让我刮目相看.

或许,应该把注意力留一点给 MySQL 了 .

--End.

 

亿万用户网站MySpace的架构经验

http://blog.csdn.net/wyzxg/archive/2009/04/19/4092951.aspx

高速增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统,以期与自身的成长同步——目前,该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分,但那些指望迈入庞大在线市场的人,可以从MySpace的成长过程学到知识。

MySpace开发人员已经多次重构站点软件、数据库和存储系统,以满足爆炸性的成长需要,但此工作永不会停息。“就像粉刷金门大桥,工作完成之时,就是重新来过之日。”(译者注:意指工人从桥头开始粉刷,当到达桥尾时,桥头涂料已经剥落,必须重新开始)MySpace技术副总裁Jim Benedetto说。

既然如此,MySpace的技术还有何可学之处?因为MySpace事实上已经解决了很多系统扩展性问题,才能走到今天。

Benedetto说他的项目组有很多教训必须总结,他们仍在学习,路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统,以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。

背景知识
当然,这么多的用户不停发布消息、撰写评论或者更新个人资料,甚至一些人整天都泡在Space上,必然给MySpace的技术工作带来前所未有的挑战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费,它们的内容数据库通常可以优化为只读模式,因为用户评论等引起的增加和更新操作很少。而MySpace是由用户提供内容,数据库很大比例的操作都是插入和更新,而非读取。

浏览MySpace上的任何个人资料时,系统都必须先查询数据库,然后动态创建页面。当然,通过数据缓存,可以减轻数据库的压力,但这种方案必须解决原始数据被用户频繁更新带来的同步问题。

MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后,必须做大量的调整和优化。Benedetto说,“但我们始终跟不上形势的发展速度。我们重构重构再重构,一步步挪到今天”。

在每个里程碑,站点负担都会超过底层系统部分组件的最大载荷,特别是数据库和存储系统。接着,功能出现问题,用户失声尖叫。最后,技术团队必须为此修订系统策略。

虽然自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百万账户

“有人花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说,“但到头来,我认为我们做对的还是比做错的多。”

----end-----

MySpace注册数到达1百万至2百万区间后,数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中,距离上次数据库系统调整不过数月。用户的提交请求被阻塞,就像千人乐迷要挤进只能容纳几百人的夜总会,站点开始遭遇“主要矛盾”,Benedetto说,这意味着MySpace永远都会轻度落后于用户需求。

 

http://www.dbanotes.net/database/ebay_storage.html

eBay 的数据量

作为电子商务领头羊的 eBay 公司,数据量究竟有多大? 很多朋友可能都会对这个很感兴趣。在这一篇
Web 2.0: How High-Volume eBay Manages Its Storage(从+1 GB/1 min得到的线索) 报道中,eBay 的存储主管 Paul Strong 对数据量做了一些介绍,管中窥豹,这些数据也给我们一个参考。

站点处理能力

  • 平均每天的 PV 超过 10 亿 ;
  • 每秒钟交易大约 1700 美元的商品 ;
  • 每分钟卖出一辆车A ;
  • 每秒钟卖出一件汽车饰品或者配件 ;
  • 每两分钟卖出一件钻石首饰 ;
  • 6 亿商品,2 亿多注册用户; 超过 130 万人把在 eBay 上做生意看作是生活的一部分。

在这样高的压力下,可靠性达到了 99.94%,也就是说每年 5 个小时多一点的服务不可用。从业界消息来看,核心业务的可用性要比这个高。

数据存储工程组控制着 eBay 的 2PB (1Petabyte=1000Terabytes) 可用空间。这是一个什么概念,对比一下 Google 的存储就知道了。每周就要分配 10T 数据出去,稍微算一下,一分钟大约使用 1G 的数据空间。

计算能力

eBay 使用一套传统的网格计算系统。该系统的一些特征数据:

  • 170 台 Win2000/Win2003 服务器;
  • 170 台 Linux (RHES3) 服务器;
  • 三个 Solaris 服务器: 为 QA 构建与部署 eBay.com; 编译优化 Java / C++ 以及其他 Web 元素 ;
  • Build 整个站点的时间:过去是 10 个小时,现在是 30 分钟;
  • 在过去的2年半, 有 200 万次 Build,很可怕的数字。

存储硬件

每个供货商都必须通过严格的测试才有被选中的可能,这些厂家或产品如下:

  • 交换机: Brocade
  • 网管软件:IBM Tivoli
  • NAS: Netapp (占总数据量的 5%,2P*0.05, 大约 100 T)
  • 阵列存储:HDS (95%,这一份投资可不小,HDS 不便宜, EMC 在 eBay 是出局者) 负载均衡与 Failover: Resonate ;

搜索功能: Thunderstone indexing system ;
数据库软件:Oracle 。大多数 DB 都有 4 份拷贝。数据库使用的服务器 Sun E10000。另外据我所知, eBay 购买了 Quest SharePlex 全球 Licence 用于数据复制.

 

应用服务器

应用服务器有哪些特点呢?

  • 使用单一的两层架构(这一点有点疑问,看来是自己写的应用服务器)
  • 330 万行的 C++ ISAPI DLL (二进制文件有 150M)
  • 数百名工程师进行开发
  • 每个类的方法已经接近编译器的限制

非常有意思,根据eWeek 的该篇文档,昨天还有上面这段划掉的内容,今天上去发现已经修改了:

架构

  • 高分布式
  • 拍卖站点是基于 Java 的,搜索的架构是用 C++ 写的
  • 数百名工程师进行开发,所有的工作都在同样的代码环境下进行

可能是被采访者看到 eWeek 这篇报道,联系了采访者进行了更正。我还有点奇怪原来"两层"架构的说法。

其他信息

  • 集中化存储应用程序日志;
  • 全局计费:实时的与第三方应用集成(就是eBay 自己的 PayPal 吧?)
  • 业务事件流:使用统一的高效可靠消息队列. 并且使用 Cookie-cutter 模式用于优化用户体验(这似乎是大型电子商务站点普遍使用的用于提高用户体验的手法)。

后记

零散作了一点流水帐。作为一个 DBA, 或许有一天也有机会面对这样的数据量。到那一天,再回头看这一篇电子垃圾。

更新:更详细信息请参考:Web 2.0: How High-Volume eBay Manages Its Storage。可能处于 Cache 的问题,好几个人看到的原文内容有差异

--EOF--

 

http://www.dbanotes.net/web/ebay_application_server.html

eBay 的应用服务器规模

前面我在《eBay 的数据量》中介绍了一些道听途说来的关于互联网巨头 eBay 服务器架构的信息,不过还缺了一点关键数据。

在 Oracle 站点上的一篇题为 The eBay Global Platform and Oracle 10g JDBC 的白皮书,有能看到一些数据。

在 2004 年的时候,eBay 的应用服务器采用了 IBM WebSphere,部署在 WinNT 上,硬件是 Intel 双 CPU 奔腾服务器。服务器数量是 2400 台。在《eBay 的数据量》中我们知道,eBay 的是集中式处理 Log 的,每天会有 2T 的 Log 数据产生,现在只会更多。这些应用服务器分成不同的组,通过一个统一的 DAL(database access layer) 逻辑层访问 135 个数据库节点。

这篇白皮书已经发布了两年,相信在这两年的时间里,服务器规模又会扩大了许多。

eBay 的 SOA 架构 V3 示意图如下:

eBay V3 架构示意图
这个图来自这里

以前我写的《这些大网站都用什么操作系统与 Web 服务器 ?》,还有网友质疑 eBay 的服务器不是 WinNT,现在倒是间接证明了 Web 服务器的确是 Windows 。

--EOF--

 

http://www.dbanotes.net/database/ebay_database_scale_out.html

eBay 的数据库分布扩展架构

在过去的 Blog 中, 我(插一嘴:这里的"我" 如果替换成 "Fenng" 似乎有些自恋, 也不是我喜欢的行文语气, 可发现转贴不留名的行为太多了,他大爷的)曾经介绍过 《eBay 的应用服务器规模》 , 也介绍过 《eBay 的数据量》,在这篇文章中提到过 "eBay 购买了 Quest Share Plex 全球 Licence 用于数据复制",这个地方其实没有说开来。

对于 eBay 这样超大规模的站点来说,瓶颈往往最容易在数据库服务器上产生,必定有一部分数据(比如交易记录这样不容易水平分割的数据)容易带来大量的读操作,而不管用什么存储,能承担的 IO 能力是有限的。所以,如果有效的分散 IO 的承载能力就是一个很有意义的事情。

经过互联网考古学不断挖掘,路路续续又现了一些蛛丝马迹能够多少说明一些问题。客观事实加上主观想象,简单的描述一下。见下图:

ebay_shareplex_F5.jpg

通过 Quest 公司的 Share Plex 近乎实时的复制数据到其他数据库节点,F5 通过特定的模块检查数据库状态,并进行负载均衡,IO 成功的做到了分布,读写分离,而且极大的提高了可用性。F5 真是一家很有创新性的公司,虽然从这个案例来说,技术并无高深之处,但方法巧妙,整个方案浑然一体。

F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块,通过调用F5专有的扩展应用校验(EAV)进程,F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的 ICMP/TCP 层进行健康检查。

这个图来自一篇《F5助力eBay数据库服务器负载均衡》的软文,真是一篇很好的软文,国外恐怕不会出现这样"含金量"极高的东西。

当然,这个技术架构可不算便宜。Quest 的 Share Plex License 很贵,而且,对于每个结点来说,都需要数据库 License 与硬件费用。但优点也很多:节省了维护成本; 数据库层面的访问也能做到 SOA; 高可用性。

国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了,对于互联网企业来说多少有点过时。

BTW: 对 Amazon 的存储架构非常感兴趣,谁/哪里能提供点线索呢?

--EOF--

 

http://xiaogui9317170.javaeye.com/blog/275559

eBay 的数据层扩展经验

网址:

 

对于 eBay ,我盲人摸象一样写了好几篇 Blog ,暂列一下:

今天又重新读了一下这篇《The eBay Architecture --Striking a balance between site stablility, feature velocity, performance, and cost》 ,觉得数据层的扩展经验也很有意思。

通过功能划分不同数据库,然后根据主要访问路径水平分割数据库。这句话太空了,类似 MySQL DB 大家常采用的 Shard 思路。

减小 DB 资源开销

数据库上没有业务逻辑 。这包括:不用存储过程; 只有少量比较简单的触发器。把CPU 开销比较高的工作迁移到应用上。这包扩:参考完整性检查(嗯,检查一下你的 DB 是否再用外键? ); 连接(Join), 排序。
应用服务器尽量 Prepared 语句以及绑定变量的广泛使用。

最小化 DB 事务

自动提交(Commit)大多数主要的数据库写操作。 客户端绝对没有事务(业务逻辑) 。这包括: 单个数据库通过匿名 PL/SQL 块进行事务管理; 没有分布式事务。对于"事务", 相关信息可以从 eBay 首席架构师 Dan Pritchett 的访谈 得到确认。没有事务更没有分布式事务这一点比较关键,这也是因为 eBay 的商业逻辑天然性质(否则也不容易做),所以可以做到 Scale Out,而最近了解到 Paypal 则因为交易逻辑比较复杂,只能是 Scale Up. Paypal 的技术信息一向比较封闭,谁能告诉我一点额外的信息呢?

 

http://xiaogui9317170.javaeye.com/blog/275556

eBay 的存储一瞥

网址:

 

前年在帖子里介绍过 eBay 数据量超过 2PB ,这么大的数据量管理和规划是需要一些艺术的,可惜网络上能得到的信息太少。最近又找到一篇关于 eBay 存储的介绍 ,这篇文章通过访问 William Crosby-Lundin (这位老兄现在已经跳槽到 SalesForce了)披露了一些数据,虽然该文距离现在有一年了,还是对我有不少参考价值。

eBay 存储团队当时 12 个人,管理 13 套存储,总容量 2PB 左右(不要刻舟求剑,现在超过 8 PB ,2008-08-04)了,8000 个左右光纤口,可用性 99.94%,工作量肯定不小。每周要起用 10TB 存储,这些存储有 75 个 LUN(也就说平均每个 LUN 135GB 左右,这个数据有些怪异)。连接到 SAN 环境的主机大约有 1000 台,数据库集群有 600 个左右,据我所知,这里的集群应该只是指 Data Guard。

这么多的数据库,I/O 开销肯定不小,如何消除存储热点呢? 该文只是笼统的说通过存储层与主机层的数据分片 达到的。如果应用上 I/O 均衡做的好一些,可能存储热点问题不会成为瓶颈。

这个存储环境的部署应该有好几年了。所以最近一两年比较火爆的存储虚拟化与 Provisioning 技术都没有大规模起用。个人觉得 eBay 这么大的数据量, Provisioning 技术对于 eBay 的环境会是比较适合的。

 

有的时候,盲人摸象 也是一种乐趣呀。

补充一下,超过 140 套集群。另外,提醒一下,这些数据是随着时间而变化的。切莫刻舟求剑。

--EOF--

 

http://www.example.net.cn/archives/2006/03/olivejournaloio.html

从LiveJournal后台发展看大规模网站性能优化方法

于敦德 2006-3-16

一、LiveJournal发展历程

LiveJournal是99年始于校园中的项目,几个人出于爱好做了这样一个应用,以实现以下功能:

  • 博客,论坛
  • 社会性网络,找到朋友
  • 聚合,把朋友的文章聚合在一起

LiveJournal采用了大量的开源软件,甚至它本身也是一个开源软件。

在上线后,LiveJournal实现了非常快速的增长:

  • 2004年4月份:280万注册用户。
  • 2005年4月份:680万注册用户。
  • 2005年8月份:790万注册用户。
  • 达到了每秒钟上千次的页面请求及处理。
  • 使用了大量MySQL服务器。
  • 使用了大量通用组件。

二、LiveJournal架构现状概况

livejournal_backend.png

三、从LiveJournal发展中学习

 

LiveJournal从1台服务器发展到100台服务器,这其中经历了无数的伤痛,但同时也摸索出了解决这些问题的方法,通过对LiveJournal的学习,可以让我们避免LJ曾经犯过的错误,并且从一开始就对系统进行良好的设计,以避免后期的痛苦。

下面我们一步一步看LJ发展的脚步。

1、一台服务器

一台别人捐助的服务器,LJ最初就跑在上面,就像Google开始时候用的破服务器一样,值得我们尊敬。这个阶段,LJ的人以惊人的速度熟悉的Unix的操作管理,服务器性能出现过问题,不过还好,可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。

最终问题出现了,网站越来越慢,已经无法通过优过化来解决的地步,需要更多的服务器,这时LJ开始提供付费服务,可能是想通过这些钱来购买新的服务器,以解决当时的困境。
毫无疑问,当时LJ存在巨大的单点问题,所有的东西都在那台服务器的铁皮盒子里装着。

LJ-backend-7.png

2、两台服务器

用付费服务赚来的钱LJ买了两台服务器:一台叫做Kenny的Dell 6U机器用于提供Web服务,一台叫做Cartman的Dell 6U服务器用于提供数据库服务。

LJ-backend-8.png

LJ有了更大的磁盘,更多的计算资源。但同时网络结构还是非常简单,每台机器两块网卡,Cartman通过内网为Kenny提供MySQL数据库服务。

暂时解决了负载的问题,新的问题又出现了:

  • 原来的一个单点变成了两个单点。
  • 没有冷备份或热备份。
  • 网站速度慢的问题又开始出现了,没办法,增长太快了。
  • Web服务器上CPU达到上限,需要更多的Web服务器。

3、四台服务器

又买了两台,Kyle和Stan,这次都是1U的,都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。

LJ-backend-9.png

LJ把Kenny用于外部的网关,使用mod_backhand进行负载均横。

然后问题又出现了:

  • 单点故障。数据库和用于做网关的Web服务器都是单点,一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持心跳同步迅速切换,但还是无法解决数据库的单点,LJ当时也没做这个。
  • 网站又变慢了,这次是因为IO和数据库的问题,问题是怎么往应用里面添加数据库呢?

4、五台服务器

又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式),写操作全部针对主数据库(通过Binlog,主服务器上的写操作可以迅速同步到从服务器上),读操作在两个数据库上同时进行(也算是负载均横的一种吧)。

LJ-backend-10.png

实现同步时要注意几个事项:

  • 读操作数据库选择算法处理,要选一个当前负载轻一点的数据库。
  • 在从数据库服务器上只能进行读操作
  • 准备好应对同步过程中的延迟,处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可,读操作不存在同步问题。

5、更多服务器

有钱了,当然要多买些服务器。部署后快了没多久,又开始慢了。这次有更多的Web服务器,更多的数据库服务器,存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。

LJ-backend-11.png

6、现在我们在哪里:

LJ-backend-1.png

现在服务器基本上够了,但性能还是有问题,原因出在架构上。

数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内,这样唯一的好处就是将读操作分布到了多台机器,但这样带来的后果就是写操作被大量分发,每台机器都要执行,服务器越多,浪费就越大,随着写操作的增加,用于服务读操作的资源越来越少。

LJ-backend-2.png

由一台分布到两台

LJ-backend-3.png

最终效果

现在我们发现,我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID,数据库也进行了备份,这么多的备份完全是对资源的浪费,属于冗余极端过度。那为什么不把数据分布存储呢?

问题发现了,开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储,以实现数据的分布式存储,让每台机器只为相对固定的用户服务,以实现平行的架构和良好的可扩展性。

为了实现用户分组,我们需要为每一个用户分配一个组标记,用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个slave组成,并且slave的数量在2-3台,以实现系统资源的最合理分配,既保证数据读操作分布,又避免数据过度冗余以及同步操作对系统资源的过度消耗。

LJ-backend-4.png

由一台(一组)中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上,所有针对用户的操作需要先查询这台机器得到用户的组号,然后再到相应的数据库组中获取数据。

这样的用户架构与目前LJ的架构已经很相像了。

在具体的实现时需要注意几个问题:

  • 在数据库组内不要使用自增ID,以便于以后在数据库组之间迁移用户,以实现更合理的I/O,磁盘空间及负载分布。
  • 将userid,postid存储在全局服务器上,可以使用自增,数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。
  • 在数据库组之间迁移用户时要万分小心,当迁移时用户不能有写操作。

7、现在我们在哪里

LJ-backend-5.png

问题:

  • 一个全局主服务器,挂掉的话所有用户注册及写操作就挂掉。
  • 每个数据库组一个主服务器,挂掉的话这组用户的写操作就挂掉。
  • 数据库组从服务器挂掉的话会导致其它服务器负载过大。

对于Master-Slave模式的单点问题,LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的,并不是由MySQL直接提供的,实际上也就是两台机器同时是Master,也同时是Slave,互相同步。

Master-Master实现时需要注意:

  • 一个Master出错后恢复同步,最好由服务器自动完成。
  • 数字分配,由于同时在两台机器上写,有些ID可能会冲突。

解决方案:

  • 奇偶数分配ID,一台机器上写奇数,一台机器上写偶数
  • 通过全局服务器进行分配(LJ采用的做法)。

 

Master-Master模式还有一种用法,这种方法与前一种相比,仍然保持两台机器的同步,但只有一台机器提供服务(读和写),在每天晚上的时候进行轮换,或者出现问题的时候进行切换。

8、现在我们在哪里

LJ-backend-6.png

现在插播一条广告,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.comLiveJournal.com的同学们拿这个文档参加了两次MySQL Con,两次OS Con,以及众多的其它会议,无私的把他们的经验分享出来,值得我们学习。在web2.0时代快速开发得到大家越来越多的重视,但良好的设计仍是每一个应用的基础,希望web2.0们在成长为Top500网站的路上,不要因为架构阻碍了网站的发展。

参考资料:http://www.danga.com/words/2005_oscon/oscon-2005.pdf

感谢向静推荐了这篇文档给我。

 

http://blog.csdn.net/yzhz/archive/2005/02/24/300500.aspx

eBay架构的思想金矿 收藏
英文来源:http://www.manageability.org/blog/stuff/about-ebays-architecture

                        杨争  /译

       了解一件事情是怎么做的一个正确的方式是看看它在现实中是怎么做的。软件工业一直以来都在为"很多idea仅仅在理论上说说"所困惑。与此同时,软件厂商不断地把这些idea作为最佳实践推销给大家。
        很少的软件开发者亲眼目睹过大规模可扩展的架构这一领域。幸运的是,有时我们可以看到和听到关于这方面公开发表的资料。我读过一些好的资料关于google的硬件基础设施的设计以及yahoo的页面渲染专利。现在,另一个互连网的巨人,eBay,给我们提供了其架构的一些资料(译者注:指的是"一天十亿次的访问-采用Core J2EE Pattern架构的J2EE 系统"这篇文章)。
        这篇文章提供了很多信息。然而,我们将只对那些独特的和我感兴趣的那部分进行评论。
        给我留下深刻印象是eBay站点的99.92%的可用性和380M page的页面数据。除此之外,每周近3万行代码的改动,清楚明白地告诉我们ebay的java代码的高度扩展性。
        eBay使用J2EE技术是如何做到这些的。eBay可扩展性的部分如下:
 
              Judicious use of server-side state
              No server affinity
              Functional server pools
              Horizontal and vertical database partitioning

        eBay取得数据访问的线性扩展的做法是非常让人感兴趣的。他们提到使用"定制的O-R mapping" 来支持本地Cache和全局Cache、lazy loading, fetch sets (deep and shallow)以及读取和提交更新的子集。 而且,他们只使用bean管理的事务以及使用数据库的自动提交和O-R mapping来route不同的数据源.
       有几个事情是非常令人吃惊的。第一,完全不使用Entity Beans,只使用他自己的O-R mapping工具(Hibernate anyone?)。 第二、基于Use-Case的应用服务器划分。第三、数据库的划分也是基于Use-Case。最后是系统的无状态本性以及明显不使用集群技术。

       下面是关于服务器状态的引用:
       基本上我们没有真正地使用server-side state。我们可能使用它,但现在我们并没有找到使用它的理由。....。如果需要状态化的话,我们把状态放到数据库中;需要的时候我们再从数据库中取。我们不必使用集群。也就不用为集群做任何工作。

        总之,你自己不必为架构一台有状态的服务器所困扰,更进一步,忘掉集群,你不需要它。现在看看功能划分:
 
       我们有一组或者一批机器,上面运行的应用是某个具体的use case,比如搜索功能有他们自己的服务器群,我们可以采用不同的调优策略,原因是浏览商品这个基本上是只读的用例和卖一件商品这个读写的用例在执行的时候是不同。在过去四五年我们一直采用水平数据库划分达到我们需要的可用性和线性扩展性。

        总之,不要把你的应用和数据库放在一个giant machine,仅仅使用servers pools,每个pools对应一个Use Case. 听起来是否类似Google的策略。

        下面是关于水平划分的一些介绍:
         基于内容的路由可以实现系统的水平线性扩展。所以,想象一下,如果eBay某天拥有6000万种商品,我们不必把这些数据存储到一台超级Sun服务器上。.....也许我们可以把这些数据库放到许多台Sun服务器,但是我们怎么取到我们需要的数据呢?eBay提出了基于内容路由的方法. 这种方法通过一定的规则,从20台物理服务器中找到我需要的数据。更cool的事情是这里还定义了failover的策略。

        最后,下面一句话描述了未来采用更加松散耦合的架构:
 
       使用消息系统来耦合不同的Use Case是我们研究的内容。

        是不是觉得很奇怪,最初这篇文章是介绍J2EE设计模式的?关键的线性扩展的思想几乎和Patterns无关。是的,eBay采用设计模式组织他们的代码。然而过分强调设计模式将失去对整体的把握。eBay架构关键的思想是无状态的设计,使用灵活的,高度优化的 OR-mapping 层以及服务器基于use cases划分。设计模式是好的,然而不能期望它使应用具有线性扩展性。

        总之,eBay和Google的例子表明以Use-Case为基础组成的服务器pools的架构比几个大型计算机证明是具有更好线性扩展性的和可用性。当然,厂商害怕听到这样的结论。然而,部署这么多服务器的最大麻烦是如何管理好他们。-)

 

我的总结:
         eBay采用设计模式达到eBay架构的分层,各层(表示层、商业逻辑层、数据访问层)之间松散耦合,职责明确,分层提高了代码的扩展性和程序开发的效率。
         eBay采用无状态的设计,灵活的、高度优化的 OR-mapping 层以及服务器基于use cases划分,达到应用之间的松散耦合,提高系统的线性扩展性。
        为什么要求系统具有可线性扩展,目的就是当网站的访问量上升的时候,我们可以不用改动系统的任何代码,仅仅通过增加服务器就可以提高整个网站的支撑量。

 

http://blog.csdn.net/yzhz/archive/2005/01/10/247116.aspx

一天十亿次的访问-eBay架构(一) 收藏
版权声明:如有转载请求,请注明出处:http://blog.csdn.net/yzhz

本文来自于2003JavaOne(http://java.sun.com/javaone/)上的一篇文章。我把它翻译成中文,有些不重要的部分我已略去。虽然是2003年的文章,但其中的J2EE设计方案还是值得我们去学习的,而且这个架构本身就是面向未来的。

eBay作为全球最大的网络交易市场赢得了市场的尊重,作为技术人员我们对其后台架构如何能够支撑起这个庞然大物都会感兴趣。每天十亿次访问量,6900万注册会员,1600万商品这些天文般的数字意味着它每天承受着巨大的并发访问量,而且eBay上大量页面都不是静态页面。

这篇介绍eBay架构的文章一定能对我们的项目设计和开发起到很好的指导作用。

eBay的架构是eBay的工程师和Sun的工程师共同设计完成的。

下面文章中斜体字是我的注释或者感想,其他的都是原文翻译。

 

作者:Deepak Alur、Arnold Goldberg、Raj Krishnamurthy

翻译:杨争

 

 

一天十亿次的访问

采用Core J2EE Pattern架构的J2EE 系统

 

详细了解Core J2EE Pattern可以查看此链接http://java.sun.com/blueprints/corej2eepatterns/Patterns/

 

目标:

通过本文,学习如何采用Core J2EE Patterns架构具有高度扩展性多层的J2EE应用。

 

作者:

Deepak Alur

- Senior Software Architect, SunPS program

- Co-author of Core J2EE Patterns

- Sun-eBay V3 Architecture—Team leader

 

Arnold Goldberg

- Lead Architect—eBay.com Platform

- Led V3 architecture, design and implementation

 

Raj Krishnamurthy

- Software Architect, SunPS program

- Sun-eBay V3 Architecture team—Key member

 

议程:

入门和Core J2EE Patterns

eBay.com三层架构的目标

关键架构和技术决策

eBay.com如何应用Core J2EE Patterns

结论

 

 

一、入门和Core J2EE Patterns

1、目标:

- eBay.com网站的架构

- 架构中模式的地位

- 使用 Core J2EE Patterns的好处

 

2、eBay介绍

(1)使命

1、全球交易平台

2、拍卖、定价、B2C、B2B

 

(2)统计数据

- 6900万注册会员

- 28000个分类,1600万商品

- 2002年营业额:148亿7千万美元

-全球社区

-每天十亿次访问量

- 1200多个URL

 

3、eBay旧的二层架构及其存在的问题

(1)ebay旧的二层架构

-集成在一起的两层架构(架构中各组件之间的耦合度高)

- 330万行C++ ISAPI DLL

-面向功能的设计

- Not for systemic qualities

 

(2)二层架构存在的问题

-阻碍商业创新(可扩展性不够)

-随着访问量增大,系统线性扩展性面临着挑战(无法通过仅仅增加硬件投入,扩充系统的支撑量)

-高额的维护成本

-不便于“重构”(代码很难通过重构来改善)

- Architects in constant Fire-Fighting Mode

 

4、2000年底开始三层架构改造

 

系统向分层、松散耦合、模块化、基于标准的架构过渡

 

中美网络 发表于2005年1月14日星期五 21:06:00  IP:举报
本页图片有问题
http://www.cnandusa.com/HArticle2369.aspx
yzhz博客专家 发表于2005年1月17日星期一 8:08:00  IP:举报
csdn的服务器有点问题。
我重新上传了一次。如果再次看不到的话,你可以访问下面的链接来查看该图片
http://www.photodump.com/direct/yz/ebayv3.jpg

http://blog.csdn.net/yzhz/archive/2005/01/10/247127.aspx

一天十亿次的访问-eBay架构(二) 收藏
版权声明:如有转载请求,请注明出处:http://blog.csdn.net/yzhz

 

5、eBay架构的改造是基于下面这本书介绍的模式

core J2EE Pattern 最佳实践和设计策略第二版,sun官方网站也提供core J2EE Pattern,见

http://java.sun.com/blueprints/corej2eepatterns/Patterns/

 

该书介绍了21 种J2EE设计模式,我们可以把他们归类到三层中。

(1)、表示层的设计模式:

- Intercepting Filter (X)

- Front Controller (X)

- Application Controller (X)

- Context Object (X)

- View Helper

- Composite View

- Service To Worker (X)

- Dispatcher View

带(X)表示这些设计模式在eBay.com的架构中采用了。

 

(2)、商业逻辑层的设计模式:

- Business Delegate

- Service Locator (X)

- Session Facade

- Application Service (X)

- Business Object (X)

- Composite Entity

- Transfer Object (X)

- Transfer Object Assembler (X)

- Value List Handler (X)

带(X)表示这些设计模式在eBay.com的架构中采用了。

 

3、集成层(也称为数据访问层) 设计模式:

- Data Access Object (X)

- Service Activator

- Domain Store (X)

- Web Service Broker (X)

带(X)表示这些设计模式在eBay.com的架构中采用了。

 

 

二、ebay三层架构的目标

1、目标

高可用性、高可靠性、可线性扩展,建立实现系统的无缝增长。

高开发效率,支持新功能的快速交付。 

可适应未来的架构,应变将来商业的更新需求。

ebay的系统可用性2002年已到了99.92%.(令人叹服),每季度网站新增十五个重大功能,

每个星期将近3万行代码在修改,3个星期内可以提供一个国际化版本。

 

2、为了可适应未来的架构,ebay采用了下面的做法

采用J2EE模式

Only adopt Technology when required

Create new Technology as needed

大量的性能测试

大量的容量计划

大量关键点的调优

Highly redundant operational infrastructure and the technology to leverage it

 

3、为了实现可线性扩展,ebay采用了下面的做法:

(1)       合理地使用server state

(2)       No server affinity

(3)       Functional server pools。

(4)       Horizontal and vertical database partitioning。

 

ebay架构采用了服务器分块化的概念,每台服务器上的应用与它的use case有关,即server pool中的一部分服务器专门用于登陆,一部分服务器专门用于显示商品信息。毕竟不同use case访问数据库的方式不同,比如“显示商品信息”use case只是只读操作。而且由于是只读操作,数据库的压力会比较低,我可以只采用几台服务器来承担这部分操作,而更多的服务器用于读写操作多的use case,这样合理地使用服务器资源。

由于不同的应用放在不同的服务器上,这里就涉及到用户状态的复制问题。这就是第一条ebay要求合理地使用server state的原因,就我所知,ebay的用户状态只有很少保存在session中,ebay把用户的状态放到了数据库和cookie中。

 

4、为了使得数据访问可线性扩展

(1)       建模我们的数据访问层

(2)       支持Support well-defined data access patterns

Relationships and traversals

本地cache和全局cache

(3)       定制的O-R mapping—域存储模式

(4)       Code generation of persistent objects

(5)       支持lazy loading

(6)       支持fetch sets (shallow/deep fetches)

(7)       支持retrieval and submit (Read/Write sets)

      

5、为了使数据存储可线性扩展,eBay采用了下列做法

(1)商业逻辑层的事务控制

只采用Bean管理的事务

Judicious use of XA

数据库的自动提交

(2)基于内容的路由

运行期间采用 O-R Mapping ,找到正确的数据源

支持数据库的水平线性扩展

Failover hosts can be defined

(3)数据源管理

动态的

Overt and heuristic control of availability

如果数据库宕机,应用可以为其他请求服务。

 

6、应变未来采用的技术

(1)消息系统

子系统之间、数据库之间松散耦合

J2EE的Message Driven Beans

(2)SOAP

对于外部开发者和合作伙伴,通过可用的工具和最佳实践来平衡我们的平台

采用SOAP 来标准化不同eBay应用之间进程内部的通信

采用SOAP满足我们的QoS需求

 

 

 

四、将J2EE的设计模式应用到eBay中

    介绍了三个Use cases例子,“查看账号”,“查看商品”,“eBayAPI”,介绍了这三个use case 如何采用J2EE的设计模式实现其设计。(略去)

 

http://blog.csdn.net/yzhz/archive/2005/01/10/247133.aspx

一天十亿次的访问-eBay架构(三) 收藏
版权声明:如有转载请求,请注明出处:http://blog.csdn.net/yzhz

五、结论

 

1、表示层架构

 

 

2、商业逻辑层架构

 

 

3、eBay整体架构

 

 

4、总结

(1)eBay.com的架构采用了J2EE核心模式

   -使你不用重新发明轮子,提高系统重用性

   -经过实践证明的解决方案和策略

   -J2EE核心模式可以成为Developer和Architect 的词汇

   -更快的开发效率

(2)在你开发项目中学习和采用这些设计模式

(3)参与到模式的社区中。

 

 

5、看了这么多,如果你能记得些什么的话,希望是下面这段话:

    模式在开发和设计中是非常有用的。模式能帮助你达到设计的重用、加快开发进度、降低维护成本,提高系统和代码的可理解性。

 

我重新上传了一下。
如果以后再看不到的话,你可以去以下链接查看:

http://www.photodump.com/direct/yz/ebaypresention.jpg
http://www.photodump.com/direct/yz/ebaybusinesslogic.jpg
http://www.photodump.com/direct/yz/ebaywhole.jpg

 

http://blog.csdn.net/yzhz/archive/2005/01/10/247140.aspx

一天十亿次的访问-eBay架构(四)

我的体会:

1、ebay架构的主体是采用J2EE的核心设计模式设计的,我们在实际项目中可根据我们应用的需求采用适合我们应用的设计模式。毕竟我们看到eBay的架构也不是用了J2EE核心设计模式中提到的所有模式,而是根据项目的实际情况采用了部分适合其本身的模式。
2、需要澄清的是:这些设计模式是J2EE的设计模式,而不是EJB的设计模式。如果你的架构没有采用EJB,你仍然可以使用这些设计模式。
3、本文中除了介绍如何采用J2EE核心模式架构eBay网站,还介绍了eBay架构为了支持线性扩展而采用的一些做法,我觉得这些做法很有特点,不仅可以大大提高系统的线性扩展性,而且也能大大提高网站的性能。这些我会有另外一篇文章介绍给大家。

 

 

抱歉!评论已关闭.