大型网站架构技术方案集锦.docx
《大型网站架构技术方案集锦.docx》由会员分享，可在线阅读，更多相关《大型网站架构技术方案集锦.docx（16页珍藏版）》请在冰豆网上搜索。
大型网站架构技术方案集锦
大型网站架构技术方案集锦-具体内容
PlentyOfFish网站架构学习
采取Windows技术路线的Web2.0站点并不多，除了MySpace，另外就是这个PlentyOfFish。
这个站点提供"OnlineDating”服务。
一个令人津津乐道的、惊人的数据是这个只有一个人（创建人MarkusFrind）的站点价值10亿，估计要让很多人眼热，更何况MarkusFrind每天只用两个小时打理网站--可操作性很强嘛。
之所以选择Windows.NET的技术路线是因为MarkusFrind不懂LAMP那一套东西，会啥用啥。
就这样，也能支撑超过3000万的日点击率（从这个数字也能看出来人类对自然天性的渴望是多迫切）。
ToddHoff收集了很多关于PlentyOfFish架构的细节。
记录一下感兴趣的部分。
带宽与CPU
PlentyOfFish比较特殊的一个地方是几乎不需要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的架构扩展
在西雅图扩展性的技术研讨会上，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网站的数据信息,有谁可以提供一点?
--EOF--
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!
维基百科网站成功的第一关键要素就是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的文章
--EOF--
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离预期目标还差的很远。
期待罗马早日建成。
--EOF--
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、联络家等站点是如何解决这个关系图的计算的呢?
--EOF--
一点题外话：
我的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都有。
Yahoo!
在DW/BI用的是Oracle，构建了一个超大数据库。
诸如yapache、yts（反向代理服务器）、yfor（提供快速失败接管）、ymon（监控），还有还有ysquid、ypan（cpan的Yahoo!
克隆）这些组件都是通过yinst来统计部署。
关于Yapache，请参考我以前写的Yapache-Yahoo!
Apache的秘密
这是Bix与DB有关的部署架构:
数据放在NetappNAS上（所以有的时候应用之慢也可以理解了），通过快照复制到其他数据中心。
Yahoo!
Mail架构：
这里面居然部署了OracleRAC，用来存储Mail服务相关的Meta数据。
非常有趣。
运营维护
监控工具主要用的是Nagios，用以监控集群。
使用标准插件，另外也有自行定制的插件。
Nagios这东西太棒了。
主动、被动检查的消息转发是通过Ymon来做到。
网管上针对SNMP的解决方案是用Yahoo！
自己Y字头的Ywatch。
这些Y字头的东西基本上外面都是找不到的。
Yahoo！
的技术其实并不那么开放。
Google在运营这方面也好不到什么地方去。
趋势图用Drraw展现。
Drraw是基于RRDtool的Web展现工具。
应用服务器的监控是被动的。
整个监控系统模块化部署。
Nagios的警告信息转发到Ywatch中心控制台。
Note:
上面所有截图版权都属于Ian（ImageCOPYRIGHT@IAN）。
如果去看那个PDF文件，你或许比我收获更多。
我只是让你知道我的想法而已。
--EOF--
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项目是一个关键因素。
--EOF--
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.
说白了就是对空间分配能够做到"按需分配"。
有些扯远了。
--EOF--
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.看起来是只存储了一些
升级会员 