YouTube网站架构

YouTube的成长速度惊人，目前每天视频访问量已达1亿，但站点维护人员很少。他们是如何管理，以实现如此强大供应能力的？被Google收购后，又在走什么样的发展道路呢？

平台

l  Apache

l  Python

l  Linux (SuSe版本)

l  MySQL

l  psyco（python->C动态编译器）

l  lighttpd（取代Apache作为视频服务器）

统计数据

l  每天高达1亿的视频访问量。

l  创建于2005年2月。

l  2006年3月，每日视频访问量达到3千万。

l  2006年7月，每日视频访问量达到1亿。

l  2个系统管理员，2个系统扩展架构师。

l  2个产品功能开发人员，2个网络工程师，1个DBA。

性能监控手段

网站维护人员每天多次重复的工作，类似于执行下面这段代码。

while (true)

{

identify_and_fix_bottlenecks();

drink();

sleep();

notice_new_bottleneck();

}

Web服务器

l  NetScalar用于实现负载均衡和对静态内容的缓存。

l  Apache运行于mod_fast_cgi模式。

l  一台Python应用服务器专门负责Web请求的路由。

l  应用服务器与各个数据库和其他类型信息源建立会话，取得所需数据并生成HTML页面。

l  通过增加服务器，一般就可以实现对Web层的扩展。

l  Python代码的效率一般不是瓶颈所在，真正瓶颈在于RPC请求。

l  Python应用的开发和发布快速灵活，这是他们能够应对激烈竞争的重要保证。

l  正常情况下，能将每个页面的响应时间控制在100ms以内。

l  利用psyco（python->C的动态编译器），通过JIT编译方法实现内部循环的优化。

l  在CPU高敏感的活动（如加密）中使用C扩展。

l  预生成某些HTML页面并缓存。

l  在数据库中实现行级缓存。

l  对Python结果对象缓存。

l  预先计算某些数据，并发送至对应应用，以形成本地缓存。这项策略目前还未大规模运用。不需要每个应用服务器都花很多时间将预先计算，并将结果数据发送到所有服务器。有一个代理机专门负责此项工作——监控数据的变化情况，预先计算并发送。

视频服务

l  成本，包括带宽、硬件购置和电力的消耗。

l  每段视频均通过刀片群集（mini-cluster）服务器管理，也就是说由多个机器联合提供视频内容服务。

l  刀片群集管理的优势：

n  多个磁盘提供内容服务，意味着更快的速度。

n  提供了动态余量。一台机器停止服务，其他可以接管。

n  实现了在线备份。

l  使用lighttpd作为视频的Web服务器：

n  Apache的成本太高。

n  使用epoll同时操作多个fds（文件描述符）。

n  从单进程切换到多进程，以处理更多连接。

l  将频繁访问的内容转移到CDN（content delivery network）：

n  CDN将内容复制到多个源，因此对用户来说，获取数据时可以选择最优路径。

n  CDN服务器主要依靠内存提供服务，否则因访问频繁，可能引起抖动。

l  低访问量的内容（每天1-20的访问量），YouTube服务器以colo模式管理。

n  长尾效应。单个视频的访问量不高，但大量视频合起来就不一样了。各磁盘块被访问到的概率是随机的。

n  在这种情况下，花费了大量投入的缓存，作用并不大。这个问题是当前研究的一个热点。如果你有一个长尾型的产品，请记住缓存不见得就是解决性能问题的救世主。

n  优化调整RAID控制器，在底层策略上下功夫。

n  调整每台服务器上的内存，不要太大也不要太小。

视频服务中的几个关键点

l  整体方案力求简洁、廉价。

l  网络路径保持最短，不要在内容和终端用户间部署太多设备。路由器、交换机等可能承受不了这么高的负载。

l  尽量采用普通硬件。高档硬件的支撑设备很昂贵，实际中往往发现它们的作用并不大。

l  使用简单、通用的工具。YouTube优先考虑Linux自带的大多数工具。

l  正确处理随机寻道问题（采用SATA、优化调整等）。

视频截图的处理

l  实现视频截图和缩略图的高效访问，有着惊人的难度。

l  如果每视频平均4个缩略图，那么总图量是非常庞大的。

l  缩略图存储在有限几台机器上。

l  大量小型对象服务中存在的难点问题：

n   磁盘寻道频繁，操作系统级inode（译者注：Linux/Unix系统中记录文件信息的对象）缓存和页缓存多。

n  每个目录受到最大文件数限制。Ext3文件系统可管理的目录层级非常多，即便依托2.6内核将大目录处理性能提高100倍左右，在文件系统中存储大量文件情况下，仍然不是一个值得称许的解决策略。

n  平均含60个缩略图的页面的访问量很大。

n  在如此高负载条件下，Apache的性能急剧下降。

n  使用squid（反向代理）作为Apache的前端，能起到一定作用。但随着负载的上升，性能最终会呈下降趋势——处理能力由原来的300个/s降为20个/s。

n  尝试使用lighttpd。这是一个单进程且单线程的应用，每个进程拥有独立缓存。为了提高性能，需要运行多个进程实例。如此一来，造成了资源浪费和性能限制等问题。

n  大量图片需要处理的情况下，向系统新增一台机器，需要24个小时。

n  重启机器后，系统需要花费6-10小时，来将内容从磁盘载入缓存。

l  为了解决这些问题，他们使用了Google的分布式数据存储策略——BigTable：

n  将文件拢在一起，避免了小文件问题。

n  速度快；即使运行在不可靠网络上，其错误率也是可以容忍的。

n  未知风险小，因为它使用了分布式的多级缓存。缓存工作于colo结构上。

数据库[DSJ2]

l  早期：

n  使用MySQL存储用户、标签和详细描述等原数据。

n  数据存储在挂10磁盘、10卷的单片RAID上。

n  租借硬件。负载上升，添加新设备时他们需要数天时间。

n  和其他很多系统一样，他们走过了这样一段历史：单服务器，主从服务器（单台主服务器，依靠多台从服务器实现读数据的负载均衡），数据库分割（逐渐稳定于分割模式）。

n  存在数据复制延迟的问题。主服务器是多线程的，硬件条件好，性能高；而从服务器运行于单线程模式，且硬件条件差一些。数据从主服务器到从服务器的复制是异步的，因此从服务器上的数据往往严重滞后于主服务器。

n  数据更新后，缓存将被清除，需从I/O更慢的磁盘读取，从而造成复制更为缓慢。

n  在这种以数据复制为中心的架构下，稍微提升写性能，都必须付出巨大成本。

n  他们的解决办法之一是将数据分割到两个不同群集，从而分解访问压力：一个视频池和一个普通群集。这个解决方案的出发点是：访问者最想看到的是视频，因此应该为这些功能分配最多资源；而YouTube社交功能是次重要的，因此做次优配置。

l  后来：

n  继续执行数据库分割策略。

n  按用户划分数据。

n  数据的读、写操作分离。

n  改进了缓存数据定位策略，减少I/O。

n  所需硬件减少了30%。

n  数据复制延迟降为0。

n  现在几乎能做到对数据库任意扩展。

数据中心策略

l  开始的时候使用托管机房。除非事先签订了协议，不能自行扩展硬件和网络系统。因此，他们后来选择了colo，可以完全按照自己的设计要求部署系统。

l  使用5/6个数据中心，外加CDN。视频的来源可以是任何一个数据中心，而非就近选择等模式。若访问频度很高，则移至CDN。

l  视频的访问性能依赖于带宽，而不是其他因素。对于图片，其他因素的影响就很大（例如页面平均图片数）。

l  利用BigTable将图片复制到各个数据中心。

经验教训

l  敢于坚持。 局部创新和一些有一定风险的策略，能够解决短期问题。如果一直坚持下去，就一定能找到长期解决方案。

l  确定事情的优先级。找出服务中的关键部分，优先为其配置资源、投入力量。

l  学会选择与合作。不要害怕将项目的关键部分外包。YouTube使用CDN向广大用户提供内容。如果完全依靠自己建设这样一个网络，需要花费的成本和时间都是惊人的。在你的系统中，应该可以存在这类同样的部件。

l  一切从简! 简单，将保证系统具有良好的可重构性以及对问题的快速响应。没有人真正知道怎么样才算是简单，如果在需要做出改变时，相关人员没有产生畏难情绪，就说明达到了简单的目标。

l  数据分割。数据分割策略将实现对磁盘、CPU、内存和IO实体和指标的优化配置，改善的不仅仅是写数据的性能。

l  对瓶颈资源做持续改善：

n  软件层：数据库、缓存

n  操作系统层：磁盘I/O

n  硬件层：内存、RAID

l  团队是成功的基础。在一个有良好纪律的团队中，所有成员都能够准确把握整个系统，了解深层问题。拥有一个好的团队，将无往而不胜。