您好,欢迎访问三七文档
当前位置:首页 > IT计算机/网络 > 网站策划/UE > 大型网站架构技术方案集锦-具体内容
1大型网站架构技术方案集锦-具体内容PlentyOfFish网站架构学习采取Windows技术路线的Web2.0站点并不多,除了MySpace,另外就是这个PlentyOfFish。这个站点提供OnlineDating”服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人MarkusFrind)的站点价值10亿,估计要让很多人眼热,更何况MarkusFrind每天只用两个小时打理网站--可操作性很强嘛。之所以选择Windows.NET的技术路线是因为MarkusFrind不懂LAMP那一套东西,会啥用啥。就这样,也能支撑超过3000万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。ToddHoff收集了很多关于PlentyOfFish架构的细节。记录一下感兴趣的部分。带宽与CPUPlentyOfFish比较特殊的一个地方是几乎不需要Cache,因为数据变化过快,很快就过期。我不知道这是因为ASP.NET的特点带来的架构特点,还是业务就是这个样子的。至于图片,则是通过CDN支撑的。对于动态出站(outbound)的数据进行压缩,这耗费了30%的CPU能力,但节省了带宽资源。我最近才知道,欧美的带宽开销也不便宜。负载均衡微软Windows网络负载均衡(NetworkLoadBalancing)的一个缺陷是不能保持Session状态(我没有用过这玩意儿,不能确认),价格也不便宜,而且复杂;网络负载均衡对Windows架构的站点又是必须--IIS的总连接数是有限制的。PlentyOfFish用的是ServerIron(ConfRefer),ServerIron使用简单,而且功能比NLB更丰富。数据库一共三台SQLServer,一台作为主库,另外两台只读数据库支撑查询。数据库性能监控用的是“Windows任务管理器。因为Cache没啥用,所以要花大力气优化DB。每个页面上调用DB次数越少越好,越简单越好,这是常识,不过不是每个人都体会那么深而已。微软好不容易找到了一个宣传案例,所以在Channel9上有一个PlentyOfFish的访谈。PlentyOfFish取自天涯何处无芳草(Plentyoffishinthesea)的意思,还挺有文化的。从这一点上看,比国内那些拉皮条的网站好一些。--EOF--YouTube的架构扩展2在西雅图扩展性的技术研讨会上,YouTube的CuongDo做了关于YouTubeScalability的报告。视频内容在GoogleVideo上有(地址),可惜国内用户看不到。KyleCordes对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(KyleCordes的介绍是本文的主要来源)简单的说YouTube的数据流量,一天的YouTube流量相当于发送750亿封电子邮件.,2006年中就有消息说每日PV超过1亿,现在?更夸张了,每天有10亿次下载以及6,5000次上传,真假姑且不论,的确是超乎寻常的海量.国内的互联网应用,但从数据量来看,怕是只有51.com有这个规模.但技术上和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.3很想了解一下国内Web2.0网站的数据信息,有谁可以提供一点?--EOF--WikiPedia技术架构学习分享维基百科(WikiPedia.org)位列世界十大网站,目前排名第八位。这是开放的力量。来点直接的数据:峰值每秒钟3万个HTTP请求每秒钟3Gbit流量,近乎375MB350台PC服务器(数据来源)架构示意图如下:Copy@MarkBergsmaGeoDNS在我写的这些网站架构的Blog中,GeoDNS第一次出现,这东西是啥?A40-linepatchforBINDtoaddgeographicalfilterssupporttotheexistentviewsinBIND,把用户带到最近的服务器。GeoDNS在WikiPedia架构中担当重任当然是由WikiPedia的内容性质决定的--面向各个国家,各个地域。负载均衡:LVS4WikiPedia用LVS做负载均衡,是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS维护的一个老问题就是监控了,维基百科的技术人员用的是pybal.图片服务器:LighttpdLighttpd现在成了准标准图片服务器配置了。不多说。Wiki软件:MediaWiki对MediaWiki的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点,参见实时性能报告,瓶颈在哪里,看这样的图树展示一目了然。另外一个十分值得重视的经验是,尽可能抛弃复杂的算法、代价昂贵的查询,以及可能带来过度开销的MediaWiki特性。Cache!Cache!Cache!维基百科网站成功的第一关键要素就是Cache了。CDN(其实也算是Cache)做内容分发到不同的大洲、Squid作为反向代理.数据库Cache用Memcached,30台,每台2G。对所有可能的数据尽可能的Cache,但他们也提醒了Cache的开销并非永远都是最小的,尽可能使用,但不能过度使用。数据库:MySQLMediaWiki用的DB是MySQL.MySQL在Web2.0技术上的常见的一些扩展方案他们也在使用。复制、读写分离......应用在DB上的负载均衡通过LoadBalancer.php来做到的,可以给我们一个很好的参考。运营这样的站点,WikiPedia每年的开支是200万美元,技术人员只有6个,惊人的高效。参考文档:Wikimediaarchitecture(PDF)ToddHoff的文章--EOF--Tailrank网站架构每天数以千万计的Blog内容中,实时的热点是什么?Tailrank这个Web2.0Startup致力于回答这个问题。5专门爆料网站架构的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离预期目标还差的很远。期待罗马早日建成。--EOF--LinkedIn架构笔记6现在是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的确切时间。步调就不一致喽。7第二个办法,用Oracle的ORA_ROWSCN(还好是Oracle10g).这个伪列包含Commit时候的SCN(SystemChangeNumber),是自增的,DB自己实现的,对性能没有影响。Ora_ROWSCN默认是数据库块级别的粒度,当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列).解决办法倒也不复杂:增加一个SCN列,默认值无限大。然后用选择比某个SCN大的值就可以界定需要的数据扔到计算服务器的内存里。ORA_ROWSCN是Ora
本文标题:大型网站架构技术方案集锦-具体内容
链接地址:https://www.777doc.com/doc-6291465 .html