YouTube 的构架

youtube YouTube增长的十分迅猛,它成立于2005年2月,一年后的2006年3月,每天已经有3000万的视频服务请求,到了2006年7月,已经达到每天近1亿的视频访问,但负责整个网站维护的人数却并没有我们想象中的那么多。比较可信的说法是:2个系统管理员,2个软件构架工程师,2个开发工程师,2个网络工程师,1个DBA。

目前YouTube所使用的平台:
Apache
Python
Linux(Suse)
MySQL
psyco,一个动态的 python->C 编译器,用于为python提速
lighttpd,用于视频内容

YouTube使用NetScaler 进行负载均衡和缓存静态内容,Apache 使用 mod_fast_cgi,请求是由一个Python应用服务器来单独处理. 应用服务器请求多个数据库和其它的资源来获取数据,再把数据组装成一个Html页面。其构造极具可扩展:可以通过增加机器来扩充大规模需要的Web层。

系统中Python不构成瓶颈,大部分的时间是花费在远程调用上 (RPC),并且Python 适合快速灵活的开发和部署,这一点于市场竞争很关健。通常每个页面的服务时间小于 100 ms 。它还使用 psyco, 一个动态的 python->C 编译器 ,使用JIT编译器的方法,以优化内部循环。 在对CPU占用率比较高的应用,如加密应用,他们使用C来进行处理。为一些处理代价比较高的请求预先生成并缓存HTML。 在数据库中实现Row级别的缓存。缓存Python对象等。

YouTube的视频存储:

每个视频都存储在一个小型集群中,所以每个视频都至少存储在一个以上的机器上,更多的磁盘来存储内容意味着更快的速度。如果一台机器down掉,其它的机器可以补上,还可以做到联机备份.
因为Apache会有多的开销,所有服务器使用lighttpd做为视频文件的web server,使用 epoll 处理 fds.
比较受欢迎的视频会移到CDN上,点击量很少的内容(一天1-20个 views的那种)会存储在相应标识的服务器上.


YouTube的缩略图处理

对每个视频都有四张缩略图与之对应,这些缩略图都是专门由单独的服务器来提供web访问,这里就会遇到存储大量小文件所遇到的问题,文件系统也像是一个数据库,对于大文件到无所谓,但对于大量的零碎小文件,磁盘的I/O可受不了,何况每个目录所能存储的文件数也有一个极限,为此YouTube使用了Linux里的页面缓存和索引节点缓存,为了突破目录的存储文件数限制,在Ext3下,将文件转移到了多层次的目录结构上,目前在2.6内核下可以将Ext3的大目录处理能力提高100倍。但是,将大量文件存储在一个文件系统下仍然不是一个太好的方法。

一个页面显示60个缩略图,在每秒高请求的情况下,这样的高负荷Apache不太适合:在前端的Apache使用反向代理squid,刚开始还算凑合,但随着负荷的增加性能下降的很明显,从能处理每秒300个请求下滑到每秒20个。于是YouTube尝试用lighttpd,但lighttpd的单线程性能实在说不过去,又通过安装多线程的mod来让lighttpd支持高并发,但每个线程又有各位独立的缓存,就这导致安装一个存储大量图片的机器要消耗24小时,重启一次也要消耗6~10个小时以填充缓存。

为了解决这个问题,他们使用了Google的BigTable,一个分布的数据存储:避免了小文件存储的问题,速度够快,容错也不错,还有较低的延迟,因为它使用了一个分布式多级高速缓存,并能跨越不同的站点。
YouTube数据库

       早年:
使用MySQL存储元数据,像用户信息,tags和视频描述。
用一个包含10块硬盘的RAID 10 Volume盘阵存储数据,由于当时经济拮据,不得不租用硬件和使用信用卡购买硬件。他们也经历了从单一服务器到一个主服务器和多个副服务器的转变经历,然后数据库分区,再解决共享问题。这时遇到的问题是:主服务器是多线程大机器,它可以处理大量的任务,但副服务器是配置不太好的机器(我怀疑可能就是普通PC)只是用来单线程的工作,所以导致副服务器的响应严重滞后,因为缓慢的I/O导致了更新数据时的缓存丢失。使用replicating architecture复制构架,也只是用大量的money换来一点点的写入性能。他们的一个解决办法就是考虑数据的优先级,把数据分成两大类:一个是视频数据池,一个是通用数据群,这样的好处是让观看视频的应用得到更多的资源,而社会网络化这样的相对不太重要的功能能被路由到小容量的集群中。

现在:
实现了数据分区。分布式的读写,更好的本地缓存策略以减少IO,并减少了30%的硬件,避免了各服务器间的滞后,并且能方便的扩展数据库。

ok,从YouTube的发展和他的构架中我们可以看到,在最初的开始就应该为将来长远的发展考虑,从应用的特点和服务重点方面去考虑整个构架和性能的扩展成本。并不断的找出系统中的瓶颈,每一次瓶颈的解决,对于用户的体验就是一次增强,对于瓶颈,要有可控的预见和分析:软件,缓存,操作系统,磁盘I/O,数据库,带宽… …
YouTube成功的另一个要素,是他有一支学科交叉的团队,我在前面提到过他们的人员构成,各有专攻,一个良好的团队,有什么事是不可能的!:Impossible is nothing.

添加评论