阅读笔记（十六）

 

YouTube 在国内是个404网站，需要FQ得见，这是有用的废话，先铺垫一下。

 

从全球网站来看，它仅次于母公司 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 网站的架构演进