YouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。这点和PlentyOfFish类似，少数人维护庞大系统。是什么原因呢？放心绝对不是靠人品，也不是靠寂寞，下面就来看看YouTube的整体技术架构吧。

平台

Apache
Python
Linux(SuSe)
MySQL
psyco，一个动态的Python到C的编译器
lighttpd代替Apache做视频查看

状态

支持每天超过1亿的视频点击量
成立于2005年2月
于2006年3月达到每天3千万的视频点击量
于2006年7月达到每天1亿的视频点击量
2个系统管理员，2个伸缩性软件架构师
2个软件开发工程师，2个 *** 工程师，1个DBA

Web服务器

1，NetScaler用于负载均衡和静态内容缓存
2，使用mod_fast_cgi运行Apache
3，使用一个Python应用服务器来处理请求的路由
4，应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面
5，一般可以通过添加更多的机器来在Web层提高伸缩性
6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC
7，Python允许快速而灵活的开发和部署
8，通常每个页面服务少于100毫秒的时间
9，使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环
10，对于像加密等密集型CPU活动，使用C扩展
11，对于一些开销昂贵的块使用预先生成并缓存的html
12，数据库里使用行级缓存
13，缓存完整的Python对象
14，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。

应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个 *** 来监听更改，预计算，然后发送。

视频服务

1，花费包括带宽，硬件和能源消耗
2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有
3，使用一个集群意味着：
-更多的硬盘来持有内容意味着更快的速度
-failover。如果一台机器出故障了，另外的机器可以继续服务
-在线备份
4，使用lighttpd作为Web服务器来提供视频服务：
-Apache开销太大
-使用epoll来等待多个fds
-从单进程配置转变为多进程配置来处理更多的连接
5，大部分流行的内容移到CDN：
-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高
-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸
6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器
-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问
-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。
-调节RAID控制并注意其他低级问题
-调节每台机器上的内存，不要太多也不要太少