大型网站架构技术方案集锦具体内容讲解Word文档下载推荐.docx
《大型网站架构技术方案集锦具体内容讲解Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《大型网站架构技术方案集锦具体内容讲解Word文档下载推荐.docx(16页珍藏版)》请在冰豆网上搜索。
--EOF--
YouTube的架构扩展
在西雅图扩展性的技术研讨会上,YouTube的CuongDo做了关于YouTubeScalability的报告。
视频内容在GoogleVideo上有(地址),可惜国内用户看不到。
KyleCordes对这个视频中的内容做了介绍。
里面有不少技术性的内容。
值得分享一下。
(KyleCordes的介绍是本文的主要来源)
简单的说YouTube的数据流量,"
一天的YouTube流量相当于发送750亿封电子邮件."
2006年中就有消息说每日PV超过1亿,现在?
更夸张了,"
每天有10亿次下载以及6,5000次上传"
真假姑且不论,的确是超乎寻常的海量.国内的互联网应用,但从数据量来看,怕是只有有这个规模.但技术上和YouTube就没法子比了.
Web服务器
YouTube出于开发速度的考虑,大部分代码都是Python开发的。
Web服务器有部分是Apache,用FastCGI模式。
对于视频内容则用Lighttpd。
据我所知,MySpace也有部分服务器用Lighttpd,但量不大。
YouTube是Lighttpd最成功的案例。
(国内用Lighttpd站点不多,豆瓣用的比较舒服。
byFenng)
视频
视频的缩略图(Thumbnails)给服务器带来了很大的挑战。
每个视频平均有4个缩略图,而每个Web页面上更是有多个,每秒钟因为这个带来的磁盘IO请求太大。
YouTube技术人员启用了单独的服务器群组来承担这个压力,并且针对Cache和OS做了部分优化。
另一方面,缩略图请求的压力导致Lighttpd性能下降。
通过HackLighttpd增加更多的worker线程很大程度解决了问题。
而最新的解决方案是起用了Google的BigTable,这下子从性能、容错、缓存上都有更好表现。
看人家这收购的,好钢用在了刀刃上。
出于冗余的考虑,每个视频文件放在一组迷你Cluster上,所谓"
迷你Cluster"
就是一组具有相同内容的服务器。
最火的视频放在CDN上,这样自己的服务器只需要承担一些"
漏网"
的随即访问即可。
YouTube使用简单、廉价、通用的硬件,这一点和Google风格倒是一致。
至于维护手段,也都是常见的工具,如rsync,SSH等,只不过人家更手熟罢了。
YouTube用MySQL存储元数据--用户信息、视频信息什么的。
数据库服务器曾经一度遇到SWAP颠簸的问题,解决办法是删掉了SWAP分区!
管用。
最初的DB只有10块硬盘,RAID10,后来追加了一组RAID1。
够省的。
这一波Web2.0公司很少有用Oracle的(我知道的只有Bebo,参见这里).在扩展性方面,路线也是和其他站点类似,复制,分散IO。
最终的解决之道是"
分区"
这个不是数据库层面的表分区,而是业务层面的分区(在用户名字或者ID上做文章,应用程序控制查找机制)
YouTube也用Memcached.
很想了解一下国内Web2.0网站的数据信息,有谁可以提供一点?
WikiPedia技术架构学习分享
维基百科(WikiPedia.org)位列世界十大网站,目前排名第八位。
这是开放的力量。
来点直接的数据:
∙峰值每秒钟3万个HTTP请求
∙每秒钟3Gbit流量,近乎375MB
∙350台PC服务器(数据来源)
架构示意图如下:
Copy@MarkBergsma
GeoDNS
在我写的这些网站架构的Blog中,GeoDNS第一次出现,这东西是啥?
"
A40-linepatchforBINDtoaddgeographicalfilterssupporttotheexistentviewsinBIND"
把用户带到最近的服务器。
GeoDNS在WikiPedia架构中担当重任当然是由WikiPedia的内容性质决定的--面向各个国家,各个地域。
负载均衡:
LVS
WikiPedia用LVS做负载均衡,是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。
LVS维护的一个老问题就是监控了,维基百科的技术人员用的是pybal.
图片服务器:
Lighttpd
Lighttpd现在成了准标准图片服务器配置了。
不多说。
Wiki软件:
MediaWiki
对MediaWiki的应用层优化细化得快到极致了。
用开销相对比较小的方法定位代码热点,参见实时性能报告,瓶颈在哪里,看这样的图树展示一目了然。
另外一个十分值得重视的经验是,尽可能抛弃复杂的算法、代价昂贵的查询,以及可能带来过度开销的MediaWiki特性。
Cache!
Cache!
维基百科网站成功的第一关键要素就是Cache了。
CDN(其实也算是Cache)做内容分发到不同的大洲、Squid作为反向代理.数据库Cache用Memcached,30台,每台2G。
对所有可能的数据尽可能的Cache,但他们也提醒了Cache的开销并非永远都是最小的,尽可能使用,但不能过度使用。
数据库:
MySQL
MediaWiki用的DB是MySQL.MySQL在Web2.0技术上的常见的一些扩展方案他们也在使用。
复制、读写分离......应用在DB上的负载均衡通过LoadBalancer.php来做到的,可以给我们一个很好的参考。
运营这样的站点,WikiPedia每年的开支是200万美元,技术人员只有6个,惊人的高效。
参考文档:
Wikimediaarchitecture(PDF)
ToddHoff的文章
Tailrank网站架构
每天数以千万计的Blog内容中,实时的热点是什么?
Tailrank这个Web2.0Startup致力于回答这个问题。
专门爆料网站架构的ToddHoff对KevinBurton进行了采访。
于是我们能了解一下Tailrank架构的一些信息。
每小时索引2400万的Blog与Feed,内容处理能力为160-200Mbps,IO写入大约在10-15MBps。
每个月要处理52T之多的原始数据。
Tailrank所用的爬虫现在已经成为一个独立产品:
spinn3r。
服务器硬件
目前大约15台服务器,CPU是64位的Opteron。
每台主机上挂两个SATA盘,做RAID0。
据我所知,国内很多Web2.0公司也用的是类似的方式,SATA盘容量达,低廉价格,堪称不二之选。
操作系统用的是DebianLinux。
Web服务器用Apache2.0,Squid做反向代理服务器。
Tailrank用MySQL数据库,联邦数据库形式。
存储引擎用InnoDB,数据量500GB。
KevinBurton也指出了MySQL5在修了一些多核模式下互斥锁的问题(ThisBug?
)。
到数据库的JDBC驱动连接池用lbpool做负载均衡。
MySQLSlave或者Master的复制用MySQLSlaveSync来轻松完成。
不过即使这样,还要花费20%的时间来折腾DB。
其他开放的软件
任何一套系统都离不开合适的Profiling工具,Tailrank也不利外,针对Java程序的Benchmark用Benchmark4j。
Log工具用Log5j(不是Log4j)。
Tailrank所用的大部分工具都是开放的。
Tailrank的一个比较大的竞争对手是Techmeme,虽然二者暂时看面向内容的侧重点有所不同。
其实,最大的对手还是自己,当需要挖掘的信息量越来越大,如果精准并及时的呈现给用户内容的成本会越来越高。
从现在来看,Tailrank离预期目标还差的很远。
期待罗马早日建成。
LinkedIn架构笔记
现在是SNS的春天,最近又有消息传言新闻集团准备收购LinkedIn。
有趣的是,LinkedIn也是Paypal黑帮成员创建的。
在最近一个季度,有两个Web2.0应用我用的比较频繁。
一个是Twitter,另一个就是LinkedIn。
LinkedIn的CTOJean-LucVaillant在QCon大会上做了”Linked-In:
Lessonslearnedandgrowthandscalability“的报告。
不能错过,写一则Blog记录之。
LinkedIn雇员有180个,在Web2.0公司中算是比较多的,不过人家自从2006年就盈利了,这在Web2.0站点中可算少的。
用户超过1600万,现在每月新增100万,50%会员来自海外(中国用户不少,也包括我).
开篇明义,直接说这个议题不讲"
监控、负载均衡”等话题,而是实实在在对这样特定类型站点遇到的技术问题做了分享。
LinkedIn的服务器多是x86上的Solaris,关键DB用的是Oracle10g。
人与人之间的关系图生成的时候,关系数据库有些不合时宜,而把数据放到内存里进行计算就是必经之路。
具体一点说,LinkedIn的基本模式是这样的:
前台应用服务器面向用户,中间是DB,而DB的后边还有计算服务器来计算用户间的关系图的。
问题出来了,如何保证数据在各个RAM块(也就是不同的计算服务器)中是同步的呢?
需要一个比较理想的数据总线(DataBus)机制。
第一个方式是用Timestamp.对记录设置一个字段,标记最新更新时间。
这个解决方法还是不错的---除了有个难以容忍的缺陷。
什么问题?
就是Timestamp是SQL调用发起的时间,而不是Commit的确切时间。
步调就不一致喽。
第二个办法,用Oracle的ORA_ROWSCN(还好是Oracle10g).这个伪列包含Commit时候的SCN(SystemChangeNumber),是自增的,DB自己实现的,对性能没有影响。
Ora_ROWSCN默认是数据库块级别的粒度,当然也可做到行级别的粒度。
唯一的缺点是不能索引(伪列).解决办法倒也不复杂:
增加一个SCN列,默认值"
无限大"
然后用选择比某个SCN大的值就可以界定需要的数据扔到计算服务器的内存里。
ORA_ROWSCN是Oracle10g新增的一个特性,不得不承认,我过去忽略了这一点。
我比较好奇的是,国内的Wealink、联络家等站点是如何解决这个关系图的计算的呢?
一点题外话:
我的LinkedInProfile(Mail:
dbanotes@).KeepinTouch!
另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。
一般人我不告诉他~~
Yahoo!
社区架构
旧金山举行的QCon会议带给我们很多新鲜的信息。
虽然没机会参加,但是看看各个网站"
晒架构"
也是个比较过瘾的事情。
请参观并收藏这个页面:
Architecturesyou'
vealwayswonderedabout。
eBay的架构和去年相比基本是换汤不换药,倒是Yahoo!
的IanFlint(这位老兄是Bix的运营总监.Bix已被雅虎收购)这个PPTYahoo!
CommunitiesArchitecture:
UnlikelyBedfellows挺有意思,披露了一些鲜为人知的信息。
Yahoo!
社区包括我们比较熟悉的del.icio.us、Flickr、Yahoo!
群组、Yahoo!
Mail、Bix等。
相当于Yahoo!
把这些属性相近的应用放到一起运营。
这个思路倒是和盛大对游戏的运营有些相近。
架构特点
有两点值得注意:
1)层次化2)模块化。
这也是大规模作业下的比较经济的途径。
软件架构
首先是操作系统已经从FreeBSD逐渐迁移到RHEL。
这怕是雅虎不得已作出来的决定吧。
FreeBSD的开发力量的确不如Linux,这也是不争的事实。
数据库上MySQL与Oracle都有。
在DW/BI用的是Oracle,构建了一个超大数据库。
诸如yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、ymon(监控),还有还有ysquid、ypan(cpan的Yahoo!
克隆)这些组件都是通过yinst来统计部署。
关于Yapache,请参考我以前写的Yapache-Yahoo!
Apache的秘密
这是Bix与DB有关的部署架构:
数据放在NetappNAS上(所以有的时候应用之慢也可以理解了),通过快照复制到其他数据中心。
Mail架构:
这里面居然部署了OracleRAC,用来存储Mail服务相关的Meta数据。
非常有趣。
运营维护
监控工具主要用的是Nagios,用以监控集群。
使用标准插件,另外也有自行定制的插件。
Nagios这东西太棒了。
主动、被动检查的消息转发是通过Ymon来做到。
网管上针对SNMP的解决方案是用Yahoo!
自己Y字头的Ywatch。
这些Y字头的东西基本上外面都是找不到的。
的技术其实并不那么开放。
Google在运营这方面也好不到什么地方去。
趋势图用Drraw展现。
Drraw是基于RRDtool的Web展现工具。
应用服务器的监控是被动的。
整个监控系统模块化部署。
Nagios的警告信息转发到Ywatch中心控制台。
Note:
上面所有截图版权都属于Ian(ImageCOPYRIGHT@IAN)。
如果去看那个PDF文件,你或许比我收获更多。
我只是让你知道我的想法而已。
Craigslist的数据库架构
(插播一则新闻:
竞拍这本《Don’tMakeMeThink》,我出价RMB85,留言的不算--不会有恶意竞拍的吧?
要Ping过去才可以,失败一次,再来)
Craigslist绝对是互联网的一个传奇公司。
根据以前的一则报道:
每月超过1000万人使用该站服务,月浏览量超过30亿次,(Craigslist每月新增的帖子近10亿条?
?
)网站的网页数量在以每年近百倍的速度增长。
Craigslist至今却只有18名员工(现在可能会多一些了)。
TimO'
reilly采访了Craigslist的EricScheide,于是通过这篇DatabaseWarStories#5:
craigslist我们能了解一下Craigslist的数据库架构以及数据量信息。
数据库软件使用MySQL。
为充分发挥MySQL的能力,数据库都使用64位Linux服务器,14块本地磁盘(72*14=1T?
),16G内存。
不同的服务使用不同方式的数据库集群。
论坛
1主(master)1从(slave)。
Slave大多用于备份.myIsam表.索引达到17G。
最大的表接近4200万行。
分类信息
1主12从。
Slave各有个的用途.当前数据包括索引有114G,最大表有5600万行(该表数据会定期归档)。
使用myIsam。
分类信息量有多大?
Craigslist每月新增的帖子近10亿条"
,这句话似乎似乎有些夸张,EricScheide说昨日就超过330000条数据,如果这样估计的话,每个月的新帖子信息大约在1亿多一些。
归档数据库
1主1从.放置所有超过3个月的帖子。
与分类信息库结构相似但是更大,数据有238G,最大表有9600万行。
大量使用Merge表,便于管理。
搜索数据库
4个集群用了16台服务器。
活动的帖子根据地区/种类划分,并使用myIsam全文索引,每个只包含一个子集数据。
该索引方案目前还能撑住,未来几年恐怕就不成了。
Authdb
1主1从,很小。
目前Craigslist在Alexa上的排名是30,上面的数据只是反映采访当时(April28,2006)的情况,毕竟,Craigslist数据量还在每年200%的速度增长。
Craigslist采用的数据解决方案从软硬件上来看还是低成本的。
优秀的MySQL数据库管理员对于Web2.0项目是一个关键因素。
F的技术信息拾零
尽管是世界上最大的图片服务网站,F在国内的名气并不是很响亮,每当提到图片服务,很多人第一个会想起Flickr.但实际上Fotolog也的确是很猛的,Alexa上的排名一直在Flickr前面,目前注册用户超过1100万.而前不久也卖了一个好价钱,9000万美金.算下来的话,1个注册用户大约9美金.Yupoo的刘平阳可以偷着算算自己的网站如果卖给老外是怎样一个价格了.
在前不久的MySQLCon2007上,Fotolog的DBAFarhanMashraqi披露了一些技术信息.(PPT下载)
与其他大多数Web2.0公司普遍用Linux不同的是,Fotolog的操作系统用的是Solaris.SolarisX86也是免费的,估计是维护人员更熟悉Solaris的操作系统而作出的选择吧.
数据库当然是使用MySQL.有32台之多,最开始的存储引擎是MyISAM,后来转向InnoDB.对于DBHA,使用DRBD(介绍),在Solaris上用MySQL,有个优化技巧是关于time
(2)系统调用的,通过调用比gethrestime()更快的gethrtime(3C)来提高性能。
可以通过设置LD_PRELOAD(32位的平台)或LD_PRELOAD_64来做到。
详细信息可以参考Sun站点上的这篇MySQL优化文章,很有参考价值。
存储也是值得一说的,Fotolog用的是SAN,还是比较贵的SAN:
3Par.这个产品可能绝大多数DBA是比较陌生的,该产品原来主打金融市场,现在也有很多Web公司使用,一个比较典型的客户代表是MySpace。
3Par的最大的特点就是ThinProvisioning。
ThinProvisioning这个词有的人翻译为"
自动精简配置"
,在维基百科的定义:
Thinprovisioningisamechanismthatappliestolarge-scalecentralizedcomputerdiskstoragesystems,SANs,andstoragevirtualizationsystems.Thinprovisioningallowsspacetobeeasilyallocatedtoservers,onajust-enoughandjust-in-timebasis.
说白了就是对空间分配能够做到"
按需分配"
有些扯远了。
Digg网站架构
本篇描述一下Digg的网站架构.
国庆期间又收集了一些关于网站架构的信息。
一直没有进行系统的整理。
越来越发现其实都是自我重复的劳动,后续的信息都是嚼别人剩下的甘蔗。
--byFenng
Digg工程师采用LAMP(Linux,Apache,MySQLandPHP)模式。
这个Alexa排名在100左右的、自我估价1.5亿美金的站点目前有超过100台的PC服务器(足够少了),可以粗略分成三个部分:
数据库服务器,Web服务器,搜索服务器。
数据库方面,和其他成功的Web2.0站点一样,也是MySQL,不过Digg稍微"
激进"
一点,用MySQL5,而且号称从MySQL4升级到5性能没有什么影响。
OLTP应用用InnoDB引擎,OLAP用MyISAM。
后端数据库的读比例达到98%,写只有2%,实际的读写比例应该高于这个数字,这应该是Digg在前端用Memcached以及APCPHPaccelerator/MCache做缓存后的效果。
在IO上似乎压力并不大。
数据库分割用Sharding(分片)的机制。
从透露出来的信息看,Digg数据量并不大,仅仅刚超30g.看起来是