大型网站架构技术方案集锦-具体内容PlentyOfFish 网站架构学习采取Windows 技术路线的Web 2.0 站点并不多，除了MySpace ，另外就是这个PlentyOfFish。

这个站点提供"Online Dating” 服务。

一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值10 亿，估计要让很多人眼热，更何况Markus Frind 每天只用两个小时打理网站--可操作性很强嘛。

之所以选择Windows .NET 的技术路线是因为Markus Frind 不懂LAMP 那一套东西，会啥用啥。

就这样，也能支撑超过3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。

Todd Hoff 收集了很多关于PlentyOfFish 架构的细节。

记录一下感兴趣的部分。

带宽与CPUPlentyOfFish 比较特殊的一个地方是几乎不需要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 BergsmaGeoDNS在我写的这些网站架构的Blog 中，GeoDNS 第一次出现，这东西是啥? "A 40-line patch for BIND to add geographical filters support to the existent views in BIND", 把用户带到最近的服务器。

GeoDNS 在WikiPedia 架构中担当重任当然是由WikiPedia 的内容性质决定的--面向各个国家，各个地域。

负载均衡：LVSWikiPedia 用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 在Web 2.0 技术上的常见的一些扩展方案他们也在使用。

复制、读写分离......应用在DB 上的负载均衡通过LoadBalancer.php来做到的，可以给我们一个很好的参考。

运营这样的站点，WikiPedia 每年的开支是200 万美元，技术人员只有6 个，惊人的高效。

参考文档：Wikimedia architecture （PDF)Todd Hoff 的文章--EOF--Tailrank 网站架构每天数以千万计的Blog 内容中，实时的热点是什么? Tailrank这个Web 2.0 Startup 致力于回答这个问题。

专门爆料网站架构的Todd Hoff对Kevin Burton进行了采访。

于是我们能了解一下Tailrank 架构的一些信息。

每小时索引2400 万的Blog 与Feed，内容处理能力为160-200Mbps，IO 写入大约在10-15MBps。

每个月要处理52T 之多的原始数据。

Tailrank 所用的爬虫现在已经成为一个独立产品：spinn3r。

服务器硬件目前大约15 台服务器，CPU 是64 位的Opteron。

每台主机上挂两个SATA 盘，做RAID 0。

据我所知，国内很多Web 2.0 公司也用的是类似的方式，SATA 盘容量达，低廉价格，堪称不二之选。

操作系统用的是Debian Linux 。

Web 服务器用Apache 2.0，Squid 做反向代理服务器。

数据库Tailrank 用MySQL 数据库，联邦数据库形式。

存储引擎用InnoDB，数据量500GB。

Kevin Burton 也指出了MySQL 5 在修了一些多核模式下互斥锁的问题(This Bug?)。

到数据库的JDBC 驱动连接池用lbpool做负载均衡。

MySQL Slave 或者Master的复制用MySQLSlaveSync来轻松完成。

不过即使这样，还要花费20％的时间来折腾DB。

其他开放的软件任何一套系统都离不开合适的Profiling 工具，Tailrank 也不利外，针对Java 程序的Benchmark 用Benchmark4j。

Log 工具用Log5j(不是Log4j)。

Tailrank 所用的大部分工具都是开放的。

Tailrank 的一个比较大的竞争对手是Techmeme，虽然二者暂时看面向内容的侧重点有所不同。

其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。

从现在来看，Tailrank 离预期目标还差的很远。

期待罗马早日建成。

--EOF--LinkedIn 架构笔记现在是SNS 的春天，最近又有消息传言新闻集团准备收购LinkedIn。

有趣的是，LinkedIn 也是Paypal 黑帮成员创建的。

在最近一个季度，有两个Web 2.0 应用我用的比较频繁。