大型网站架构技术方案集锦-具体内容讲解

大型网站架构技术方案集锦-具体内容

PlentyOfFish 网站架构学习

采取Windows 技术路线的Web 2.0 站点并不多，除了MySpace ，另外就是这个PlentyOfFish。这个站点提供"Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值10 亿，估计要让很多人眼热，更何况Markus Frind 每天只用两个小时打理网站--可操作性很强嘛。

之所以选择Windows .NET 的技术路线是因为Markus Frind 不懂LAMP 那一套东西，会啥用啥。就这样，也能支撑超过3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于PlentyOfFish 架构的细节。记录一下感兴趣的部分。

带宽与CPU

PlentyOfFish 比较特殊的一个地方是几乎不需要Cache，因为数据变化过快，很快就过期。我不知道这是因为 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了30% 的CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。

负载均衡

微软Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均衡对Windows 架构的站点又是必须--IIS 的总连接数是有限制的。PlentyOfFish 用的是ServerIron

(Conf Refer)，ServerIron 使用简单，而且功能比NLB 更丰富。

数据库

一共三台SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器"。因为Cache没啥用，所以要花大力气优化DB。每个页面上调用DB 次数越少越好，越简单越好，这是常识，不过不是每个人都体会那么深而已。

微软好不容易找到了一个宣传案例，所以在Channel 9 上有一个PlentyOfFish 的访谈。

PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。

--EOF--

YouTube 的架构扩展

在西雅图扩展性的技术研讨会上，YouTube 的Cuong Do 做了关于YouTube Scalability的报告。视频内容在Google Video 上有(地址)，可惜国内用户看不到。

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

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

WikiPedia 技术架构学习分享

维基百科()位列世界十大网站，目前排名第八位。这是开放的力量。

来点直接的数据：

∙峰值每秒钟3万个HTTP 请求

∙每秒钟3G bit 流量, 近乎375MB

∙350 台PC 服务器(数据来源)

架构示意图如下：

Copy @Mark Bergsma

GeoDNS

在我写的这些网站架构的Blog 中，GeoDNS 第一次出现，这东西是啥? "A 40-line patch for BIND to add geographical filters support to the existent views in BIND", 把用户带到最近的服务器。GeoDNS 在WikiPedia 架构中担当重任当然是由WikiPedia 的内容性质决定的--面向各个国家，各个地域。

负载均衡：LVS