大型Web2.0站点构建技术初探

二、 Flickr的幕后故事

我们都看到 Flickr 的成功，而又有多少"精英"们了解过 Flickr 背后的过程是多么充满艰险。

Flickr 是全 CGI 的动态构架，并以一种 .gne 的脚本作为 CGI 程序语言。不管网站制作菜鸟还是高 手都会疑惑：gne 是哪种程序语言？答案：gne 不是一种语言，Flickr 是以极为经典的 PHP + MySQL 方 式实现的，在被 Yahoo 收购服务器搬入美国之前，使用了 21 台（69.90.111.101-121） Apache/PHP 做 Web、23 台图片服务器、另有 MySQL 服务器组成的数据库集群的服务器数量未知。现在估计使用的是 Yahoo 的负载均衡系统，对外只有一个 Web 的 IP 和图片服务器的 IP 了。

那为何 .php 的文件要改成 .gne 呢？以往有大型网站为向后兼容性考虑，隐藏以程序语言命名的脚 本文件扩展名，比如 Baidu 隐藏了 .php（Google 的 http 服务器是自己写的，整合了脚本程序，个别 页面是 .py--Python）；还有一些网站是改成自己网站名相关的扩展名，如 MSN 的群组则是 .msnw，榕 树下是 .rs。

那 Flickr 的 gne 是什么意思？我在维基百科的 Flickr 条目上找到了答案(中文 Flickr 条目上没 有写明) 。原来 GNE 是 Game NeverEnding 的缩写，Flickr 的开发者 Ludicorp 在 2002-2004 年一直 在开发这套以 Game NerverEnding 为名称的大型多人在线角色扮演游戏--一套基于浏览器的 Web 游戏系 统，个人以为应该就是当年九城的虚拟城市。但是开发近 3 年后该计划不得不破产，最终只发布了一个 Beta 版，而 Ludicorp 将这套系统稍加移植，就有了 Flickr。呵呵，原来 gne 是一个项目的名称。关 于 GNE 的一些连接：http://del.icio.us/schee/gne。

早期的 Flickr 想做成在类似聊天室的地方让网友分享、交流自己的照片，注重社区形式和保护照片 不被外部引用（见徐子涵2004年的文章），可能是看到了 Hello 的模式吧。但是聪明的 Flickr 团队不 久就改变了策略，淡化了传统的社区形式--如聊天室、而加强了现在使其功成名就的 Tag 组织形式，一 种更自由更随兴更轻松好玩的大社区形式，或者叫它广义社区吧，我随便叫的，可能太学究，看着别太在 意就是了。另外，将原来照片只能在 Flash 内浏览的限制区除了，并大力推荐用户将照片引用到自己的 Blog，这无疑对于挑战传统相册系统有决定性意义。减少 Flash 后的网页更多地引进了新兴的 Ajax 技 术，使界面操作变得非常 Cool。

这就是 Flickr 的历史，清晰地看到了他们对于优秀产品的执著。有了技术和经验积累，加上不断坚 持，总有一天时来运转，你的产品会成为新潮流的里程碑。

还有一句话要告诉 Yupoo 等：把 Flickr 想成一个有 Tag 功能的在线相册就已经错远了；复制粘贴 者们想当然将 Flickr 去其糟粕取其精华，结果无关紧要的拿来了，将令人激动的优点都去掉了，结果剩 下什么？

三、 YouTube 的架构扩展

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

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

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

1. Web 服务器

YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量 不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)

2. 视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页 面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组 来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起 用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了 刀刃上。

出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同 内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。 YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的 工具，如 rsync, SSH 等，只不过人家更手熟罢了。

3. 数据库

YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸 的问题，解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很 少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分 散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

YouTube 也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

四、 mixi.jp：使用开源软件搭建的可扩展SNS网站

Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相 册等等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO - Batara Kesuma一个人 焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一 年里，用户增长到了21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以 每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃用户：三天内至少登录一次的用户），平均 每个用户每周在线时间为将近3个半小时。

下面我们来看它的技术架构。Mixi采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL， Perl 5.8，memcached，Squid等等。到目前为止已经有100多台MySQL数据库服务器，并且在以每月10多台 的速度增长。Mixi的数据库连接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以 InnoDB方式运行。Mixi解决扩展问题主要依赖于对数据库的切分。

首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的 ID将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应 用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时 候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多 就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的话那就累了。

这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的 用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用 了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就可以 解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载 时间在0.02秒左右（当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi一共在32 台机器上有缓存服务器，每个Cache Server 2G内存，这些Cache Server与App Server装在一起。因为 Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可 以和平共处，更有效的利用资源。

图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的， 像用户头像，群组的头像等等，大概有100多GB，它们被Squid和CDN所缓存，命中率相对比较高；另一部 分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划算，所 以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行 访问，当然图片的位置需要在数据库中进行记录，不然找不到放在哪台服务器上就郁闷了。