大型网站架构技术方案集锦

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流量,近乎375MB350台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