YouTube 在国内是个404网站，需要翻墙得见，这是有用的废话，先铺垫一下。
从全球网站来看，它仅次于母公司 Google，全球排名位列第2。每天超过5亿以上视频播放量，平均每个用户点击10-15个视频。
-
Apache
-
Python
-
Linux(SuSe)
-
MySQL
-
psyco，一个动态的Python到C的编译器
-
lighttpd代替Apache做视频播放
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对象（类似于php中的OpCode或Java的ByteCode）
14、有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中—注：这个策略有些使用不当。
视频服务架构关键点
1、保持简单和低成本
2、保持简单网络拓扑，内容和用户之间不要有太多路由
3、使用常用硬件，使用昂贵的硬件找到帮助文档也不易
4、使用简单常见的工具，构建在Linux平台，以及其上的工具
5、很好的处理随机查找(SATA，tweaks)
数据库
1，早期
-
使用MySQL来存储元数据，如用户，标签（tags）和视频文字介绍、评论信息
-
使用一个RAID 10的磁盘阵列来存储数据
-
YouTube经过一个常见系统的架构演进：
从单服务器开始，然后单master和多read slave，接着做数据库partition分区，然后再hash sharding方式
-
备份慢的痛苦。master数据库是多线程的并且运行在一个大型机上，可以处理许多工作；slave是单线程的且运行在小一些的服务器上，备份是异步的，所以slave会远远慢于master主机
-
更新引起缓存失效，硬盘的I/O缓慢导致备份迟延
-
使用备份架构花费不少钱来增加写的性能
-
YouTube解决方案把数据分成两个集群来将传输分出优先次序：一个视频查看的数据库集群，另一个是处理其它业务的集群。
2，后期
-
数据库分区
分成shardings，不同的用户被分发到不同的sharding
-
扩散读写
-
更好的缓存位置意味着更少的I/O
硬件设备减少30%
-
备份延迟降低到0
-
到现在，可以任意提升数据库的伸缩
- 原文部分转载：
YouTube 网站的架构演进