YouTube架构学习体会 - IT青藤屋 - 青藤园

Skip to main content.

IT青藤屋

Article date: 关注架构、关注前端、关注生活，愿天下的程序员像常青藤一样绿意盎然、自强不息 Navigation:

• 青藤园首页
• 首页
• 订阅
• 写博客

  公告

今天让我感到了知识产权对作者的重要性，博客中的文章如果没有特殊说明，均为原创或者翻译，转载请注明原文出处。另外，在我博客中的一些文章，或许有意无意侵犯了您的知识产权，如果您发现了，请及时发邮件联系我，我将立即作出处理。我的邮箱：

sxwgf.com@gmail.com

谢谢！

如果能成为巨人，我愿意献出肩膀 王国峰 2011年毕业于 中国计量学院

我的博客园 Email联系我

文章分类

• (rss)网站架构 (57)
• (rss)程序人生 (46)
• (rss)Web前端 (64)
• (rss)云计算 (5)
• (rss)交互设计 (36)
• (rss)其他 (13)
• (rss)个人日记 (5)
• (rss)互联网资讯 (54)
• (rss)数据库 (5)
• (rss)Javascript游戏 (22)
• (rss).NET技术 (23)
• (rss)jQuery插件 (35)
• (rss)设计模式 (4)

  搜索

文章归档

• 2012年4月 (1)
• 2012年3月 (6)
• 2012年2月 (12)
• 2012年1月 (21)
• 2011年12月 (19)
• 2011年11月 (38)
• 2011年10月 (29)
• 2011年9月 (18)
• 2011年8月 (36)
• 2011年7月 (38)
• 2011年6月 (69)
• 2011年5月 (28)
• 2011年4月 (14)
• 2011年3月 (36)

• 2011年2月 (26)

  最新评论

• COOKIES如今很多浏览器都比较讨厌。

• 这个效果还是不错的，比较适合一些大的文章站。
• 很好的东西，正在看
• 果断收藏
• 我以为你说的是rotate3Di的原理呢。。。
• 还有就是用又拍云存储或者阿里云的话可以提升各地用户访问的速度
• 图片服务器和web服务器分离还有一个好处就是用户上传的带有代...
• 博主翻译的真辛苦！
• 这个滑动菜单有个BUG，index.html中<ahe...
• 我怎么连接失败呢

阅读排行

• Flickr 网站架构分析(12957)
• 我是如何用IPV6快速“翻墙”的(12156)
• 回顾MySpace架构的坎坷之路(11723)
• 优酷网架构学习笔记(10581)
• PlentyOfFish.com .NET网站的又一传奇(8971)
• 分享10个2011最佳flash网站(8533)
• 30个基于jQuery的日期时间选择插件(8475)
• 45个非常漂亮的jQuery导航插件(7540)
• jQuery图表插件Flot中文文档(7136)

• 纯CSS画的基本图形（矩形、圆形、三角形、多边形、爱心、八卦等），NB么(6932)

  评论排行

• 我是如何在12周内由零基础成为一名程序员的(22)

• 漫画：为什么搞计算机工作的人总是看上去很清闲(10)
• Flickr 网站架构分析(8)
• 因为喜欢，仅此而已(8)
• 优酷网架构学习笔记(7)
• 我们是该告CSDN还是FK了CSDN？(7)
• 在中国，我们的知识产权真的陨落了吗？(7)
• 图片存储架构学习：独立的图片服务器，给爱一个独立的空间(6)
• 20个jquery表格插件(5)
• 纯CSS画的基本图形（矩形、圆形、三角形、多边形、爱心、八卦等），NB么(5)

我的书屋

友情链接

• klvoek（温金鹿）
• NinoFocus（倪朱国）
• Android Studio
• jQuery资源宝库
• php开发园地
• 皮皮书屋（一个很好的电子书网站）
• Android开发者

YouTube架构学习体会

这几天一直在关注和学习一些大型网站的架构，希望有一天自己也能设计一个高并发、高容错的系统并能应用在实践上。今天在网上找架构相关的资料时，看到一个被和谐的视频网站YouTube的架构分析，看了以后觉得自己又向架构走近了一步，于是赶快拿出来与大家一起分享。

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

平台

---

1

2 3

4 5

6 Apache

Python Linux(SuSe)

MySQL psyco，一个动态的Python到C的编译器

lighttpd代替Apache做视频查看

状态

---

1

2 3

4 5

6 支持每天超过1亿的视频点击量

成立于2005年2月 于2006年3月达到每天3千万的视频点击量

于2006年7月达到每天1亿的视频点击量 2个系统管理员，2个伸缩性软件架构师

2个软件开发工程师，2个网络工程师，1个DBA

Web服务器

---

1

2 3

4 5

6 7

8 9

10 11

12 13

14 151，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 3

4 5

6 7

8 9

10 11

12 13

14 15

16 17

18 1，花费包括带宽，硬件和能源消耗

2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有 3，使用一个集群意味着：

-更多的硬盘来持有内容意味着更快的速度

-failover。如果一台机器出故障了，另外的机器可以继续服务

-在线备份 4，使用lighttpd作为Web服务器来提供视频服务：

-Apache开销太大

-使用epoll来等待多个fds

-从单进程配置转变为多进程配置来处理更多的连接 5，大部分流行的内容移到CDN：

-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高

-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸

6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器

-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问

-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。

-调节RAID控制并注意其他低级问题

-调节每台机器上的内存，不要太多也不要太少

视频服务关键点

1

2 3

4 51，保持简单和廉价

2，保持简单网络路径，在内容和用户间不要有太多设备 3，使用常用硬件，昂贵的硬件很难找到帮助文档

4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具 5，很好的处理随机查找(SATA，tweaks)缩略图服务

1

2 3

4 5

6 7

8 9

10 11

12 13

14 15

16 171，做到高效令人惊奇的难

2，每个视频大概4张缩略图，所以缩略图比视频多很多 3，缩略图仅仅host在几个机器上

4，持有一些小东西所遇到的问题：

-OS级别的大量的硬盘查找和inode和页面缓存问题

-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让 Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意

-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图

-在这种高负载下Apache表现的非常糟糕

-在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个

-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存

-如此多的图片以致一台新机器只能接管24小时

-重启机器需要6-10小时来缓存 5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：

-避免小文件问题，因为它将文件收集到一起

-快，错误容忍

-更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作

-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable

数据库

1

2 3

4 5

6 7

8 9

10 11

12 13

14 15

16 171，早期

-使用MySQL来存储元数据，如用户，tags和描述

-使用一整个10硬盘的RAID 10来存储数据

-依赖于信用卡所以YouTube租用硬件

-YouTube经过一个常见的革命：单服务器，然后单master和多read slaves，然后数据库分区，然后sharding方式

-痛苦与备份延迟。master数据库是多线程的并且运行在一个大机器上所以它可以处理许多工作，slaves是单线程的并且通常运行在小一些的服务器上并且备份是异步的，所以slaves会远远落后于master

-更新引起缓存失效，硬盘的慢I/O导致慢备份

-使用备份架构需要花费大量的money来获得增加的写性能

-YouTube的一个解决方案是通过把数据分成两个集群来将传输分出优先次序：一个视频查看池和一个一般的集群

2，后期

-数据库分区

-分成shards，不同的用户指定到不同的shards

-扩散读写

-更好的缓存位置意味着更少的IO

-导致硬件减少30%

-备份延迟降低到0

-现在可以任意提升数据库的伸缩性数据中心策略

1

2 3

4 5

6 7

8 1，依赖于信用卡，所以最初只能使用受管主机提供商

2，受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议 3，YouTube改为使用colocation arrangement。现在YouTube可以自定义所有东西并且协定自己的契约

4，使用5到6个数据中心加CDN 5，视频来自任意的数据中心，不是最近的匹配或其他什么。如果一个视频足够流行则移到CDN

6，依赖于视频带宽而不是真正的延迟。可以来自任何colo 7，图片延迟很严重，特别是当一个页面有60张图片时

8，使用BigTable将图片备份到不同的数据中心，代码查看谁是最近的学到的东西

1

2 3

4 5

6 7

8 9

10 111，Stall for time。创造性和风险性的技巧让你在短期内解决问题而同时你会发现长期的解决方案

2，Proioritize。找出你的服务中核心的东西并对你的资源分出优先级别 3，Pick your battles。别怕将你的核心服务分出去。YouTube使用CDN来分布它们最流行的内容。创建自己的网络将花费太多时间和太多money

4，Keep it simple！简单允许你更快的重新架构来回应问题 5，Shard。Sharding帮助隔离存储，CPU，内存和IO，不仅仅是获得更多的写性能

6，Constant iteration on bottlenecks：

-软件：DB，缓存

-OS：硬盘I/O

-硬件：内存，RAID

7，You succeed as a team。拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队，如安装打印机，安装机器，安装网络等等的人。

With a good team all things are possible。

分享到： QQ空间 新浪微博 人人网 更多 6 标签： 高性能, 架构, YouTube, 视频

Posted by ivy @ 2011-3-6 20:53:24 阅读(6410) 评论(2) 上一篇：【IE6.0 Bug总结之二】双倍边距(margin)的bug 下一篇：WikiPedia技术架构学习笔记

Feedback

1. 回复 2011-10-28 14:45:36 by pc 牛
2. 回复 2013-1-24 14:43:45 by Godaddy 优惠码 没图片看不懂啊 你还可以输入600/600个字符 发表评论

称呼： (必填) 登录 | 开通博客 邮箱： (选填) 你的邮箱地址不会被公开

网站： (选填) ")")")

验证码： (必填) 看不清楚换一张

Copyright © ivy 2011 . Powered by 青藤园 Courtesy of Open Web Design & Hotels - Dubai