YouTube网站技术架构分析

来自

第

百度

1

页

共

26

页

1

YouTube

网站架构

文

/

Todd Hoff

译

/

罗小平

文库

YouTube

的成长速度惊人，

目前每天视频访问量已达

1

亿，

但站点维护人员很少。

他们是如何管理，以实现如此强大供应能力的？被

Google

收购后，又在走什么样的

发展道路呢？

1.1

平台

l

Apache

l

Python

l

Linux

(SuSe

版本

)

l

MySQL

l

psyco

（

python->C

动态编译器）

l

lighttpd

（取代

Apache

作为视频服务器）

1.2

统计数据

l

每天高达

1

亿的视频访问量。

l

创建于

2005

年

2

月。

l

2006

年

3

月，每日视频访问量达到

3

千万。

l

2006

年

7

月，每日视频访问量达到

1

亿。

l

2

个系统管理员，

2

个系统扩展架构师。

l

2

个产品功能开发人员，

2

个网络工程师，

1

个

DBA

。

1.3

性能监控手段

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

while (true)

{

identify_and_fix_bottlenecks();

drink();

sleep();

notice_new_bottleneck();

第

2

页

共

26

页

}

1.4

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

预先计算某些数据，并发送至对应应用，以形成本地缓存。这项策略目前还未大

规模运用。不需要每个应用服务器都花很多时间将预先计算，并将结果数据发送

到所有服务器。有一个代理机专门负责此项工作——监控数据的变化情况，预先

计算并发送。

1.5

视频服务

l

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

l

每段视频均通过刀片群集（

mini-cluster

）服务器管理，也就是说由多个机器联

合提供视频内容服务。

l

刀片群集管理的优势：

n

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

n

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

第

3

页

共

26

页

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

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

第

4

页

共

26

页

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

结构上。

1.6

数据库

l

早期：

n

使用

MySQL

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

n

数据存储在挂

10

磁盘、

10

卷的单片

RAID

上。

n

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

n

和其他很多系统一样，

他们走过了这样一段历史：

单服务器，

主从服务器

（单

台主服务器，依靠多台从服务器实现读数据的负载均衡），数据库分割（逐

渐稳定于分割模式）。

n

存在数据复制延迟的问题。主服务器是多线程的，硬件条件好，性能高；而

从服务器运行于单线程模式，且硬件条件差一些。数据从主服务器到从服务

器的复制是异步的，因此从服务器上的数据往往严重滞后于主服务器。

第

5

页

共

26

页

n

数据更新后，缓存将被清除，需从

I/O

更慢的磁盘读取，从而造成复制更为

缓慢。

n

在这种以数据复制为中心的架构下，

稍微提升写性能，

都必须付出巨大成本。

n

他们的解决办法之一是将数据分割到两个不同群集，从而分解访问压力：一

个视频池和一个普通群集。这个解决方案的出发点是：访问者最想看到的是

视频，

因此应该为这些功能分配最多资源；

而

YouTube

社交功能是次重要的，

因此做次优配置。

l

后来：

n

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

n

按用户划分数据。

n

数据的读、写操作分离。

n

改进了缓存数据定位策略，减少

I/O

。

n

所需硬件减少了

30%

。

n

数据复制延迟降为

0

。

n

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

1.7

数据中心策略

l

开始的时候使用托管机房。

除非事先签订了协议，

不能自行扩展硬件和网络系统。

因此，他们后来选择了

colo

，可以完全按照自己的设计要求部署系统。

l

使用

5/6

个数据中心，外加

CDN

。视频的来源可以是任何一个数据中心，而非就

近选择等模式。若访问频度很高，则移至

CDN

。

l

视频的访问性能依赖于带宽，而不是其他因素。对于图片，其他因素的影响就很

大（例如页面平均图片数）。

l

利用

BigTable

将图片复制到各个数据中心。

1.8

经验教训

l

敢于坚持。

局部创新和一些有一定风险的策略，能够解决短期问题。如果一直

坚持下去，就一定能找到长期解决方案。

l

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

第

6

页

共

26

页

l

学会选择与合作。不要害怕将项目的关键部分外包。

YouTube

使用

CDN

向广大用

户提供内容。如果完全依靠自己建设这样一个网络，需要花费的成本和时间都是

惊人的。在你的系统中，应该可以存在这类同样的部件。

l

一切从简

!

简单，将保证系统具有良好的可重构性以及对问题的快速响应。没有

人真正知道怎么样才算是简单，如果在需要做出改变时，相关人员没有产生畏难

情绪，就说明达到了简单的目标。

l

数据分割

。

数据分割策略将实现对磁盘、

CPU

、

内存和

IO

实体和指标的优化配置，

改善的不仅仅是写数据的性能。

l

对瓶颈资源做持续改善：

n

软件层：数据库、缓存

n

操作系统层：磁盘

I/O

n

硬件层：内存、

RAID

l

团队是成功的基础。在一个有良好纪律的团队中，所有成员都能够准确把握整个

系统，了解深层问题。拥有一个好的团队，将无往而不胜。

2

YouTube

的架构扩展

在

西雅图扩展性的技术研讨会

上，

YouTube

的

Cuong Do

做了关于

YouTube

Scalability

的报告。

视频内容在

Google

Video

上有

(

地址

)

，

可惜国内用户看不到。

Kyle

Cordes

对这个视频中的内容做了

介绍

。里面有不少技术性的内容。值得分享一

下。

(Kyle Cordes

的介绍是本文的主要来源

)

简单的说

YouTube

的数据流量

, "

一天的

YouTube

流量相当于发送

750

亿封电子邮

件

.",

2006

年中就有消息说每日

PV

超过

1

亿

,

现在

?

更夸张了

,"

每天有

10

亿次下

载以及

6,5000

次上传

",

真假姑且不论

,

的确是超乎寻常的海量

.

国内的互联网应用

,

但从数据量来看

,

怕是只有

51.com

有这个规模

.

但技术上和

YouTube

就没法子比

了

.

Web

服务器

YouTube

出于开发速度的考虑，大部分代码都是

Python

开发的。

Web

服务器有部分

是

Apache

，

用

FastCGI

模式。对于视频内容则用

Lighttpd

。据我所知，

MySpace

第

7

页

共

26

页

也有部分服务器用

Lighttpd

，

但量不大。

YouTube

是

Lighttpd

最成功的案例。

(

国

内用

Lighttpd

站点不多，

豆瓣

用的比较舒服。

by

Fenng

)

视频

视频的缩略图

(Thumbnails)

给服务器带来了很大的挑战。

每个视频平均有

4

个缩略图，

而每个

Web

页面上更是有多个，每秒钟因为这个带来的磁盘

IO

请求太大。

YouTube

技术人员启用了单独的服务器群组来承担这个压力，并且针对

Cache

和

OS

做了部

分优化。

另一方面，

缩略图请求的压力导致

Lighttpd

性能下降。

通过

Hack

Lighttpd

增加更多的

worker

线程很大程度解决了问题。而最新的解决方案是起用了

Google

的

BigTable

，

这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢

用在了刀刃上。

出于冗余的考虑，

每个视频文件放在一组迷你

Cluster

上，

所谓

"

迷你

Cluster"

就

是一组具有相同内容的服务器。最火的视频放在

CDN

上，这样自己的服务器只需要

承担一些

"

漏网

"

的随即访问即可。

YouTube

使用简单、廉价、通用的硬件，这一点和

Google

风格倒是一致。至于维护手段，也都是常见的工具，如

rsync, SSH

等，只

不过人家更手熟罢了。

数据库

YouTube

用

MySQL

存储元数据

--

用户信息、视频信息什么的。数据库服务器曾经一

度遇到

SWAP

颠簸的问题，解决办法是删掉了

SWAP

分区

!

管用。

最初的

DB

只有

10

块硬盘，

RAID

10

，

后来追加了一组

RAID

1

。

够省的。

这一波

Web

2.0

公司很少有用

Oracle

的

(

我知道的只有

Bebo

,

参见这里

).

在扩展性方面，

路线

也是和其他站点类似，复制，分散

IO

。最终的解决之道是

"

分区

",

这个不是数据库层

面的表分区，

而是业务层面的分区

(

在用户名字或者

ID

上做文章

,

应用程序控制查找

机制

)

YouTube

也用

Memcached

.

很想了解一下国内

Web 2.0

网站的数据信息

,

有谁可以提供一点

?

第

8

页

共

26

页

3

YouTube Architecture

3.1

Architecture

prior

to

the

acquisition

of

YouTube

by

Google

1. YouTube video delivery framework

2. Classifying YouTube server IP addresses

The

IP

addresses

of

front-end

web

servers

were

all

mapped

to

www.youtube.com.

The IP addresses of video-servers were mapped to host names of the format:

loc-v xx.loc.youtube.com

(e.g., dal-v 26.dal.youtube.com)

loc is one of the 8 city codes: ash, chi, dal, lax, mia, nyc,sjc, sjl;

xx is an integer.

第

9

页

共

26

页

3.

Proportional load balancing of Client-to-YouTube traffic

Distribution of client traffic to YouTube data centers

The fraction of tra

ﬃ

c received by each YouTube data center from each PoP is

the same for all PoPs

The balancing strategy was not based on network/geographi

c “proximity”.

第

10

页

共

26

页

Tra

ﬃ

c

coming

from

clients

is

distributed

to

7

YouTube

data

centers

according to ﬁxed proportions.

4. Load balancing among 3 font-end web servers

YouTube

front-ends

employs

the

round-robin

DNS

resolution

for

mapping

www.youtube.com to the IP addresses of front-end web servers.

5. Proportional load balancing of YouTube-to-client Traffic

Traffic distribution from YouTube data centers to clients

Traffic distribution from YouTube data centers to various clients

第

11

页

共

26

页

The distribution of incoming video-requests to its data centers was based on

the “size” or the “resources” available at those data

centers.

3.2

Architecture

after

the

acquisition

of

YouTube

by

Google

1. High level sequence of steps to retrieve content.

YouTube servers can be both present inside an ISP, or in the Google network.

Since

2009

Google

has

migrated

most

content

from

the

YouTube

original

infrastructure

(that

was

based

on

third

party

CDNs)

to

its

own

CDN.

This

contrasts with earlier studies such as [7], [8], according to which the majority

第

12

页

共

26

页

of servers were located in the YouTube AS.

2. Geolocation of servers

Five datasets:

ISP Networks: EU1-ADSL, EU1-FTTH, EU2

Campus Network: US-Campus, EU1-Campus

As for a total of 33 data centers adopted in the experiment, 14 of them are in

Europe, 13 in USA and 6 in other places around the world.

3. Server selection algorithm

A. Video flows and sessions

V

ideo ﬂows

: long connections carrying the requested video.

Control

ﬂ

ows: short connections carrying signaling messages.

Video session: an isolated video flow not preceded by any control flow

Redirection:

server

A

may

not

serve

the

content

and

redirect

the

user

to

another content server B.

CDF of YouTube flow size

第

13

页

共

26

页

Number of flows per session for all datasets

It

shows

that

72.5

−

80.5%

of

the

sessions

consist

of

a

single

(long)

ﬂow.

Therefore,

normally

there

is

no

need

to

iterate

over

different

servers

to

download the video data. However, 19.5−27.5% of

the sessions consist of at

least

2

ﬂows,

showing

that

the

use

of

application-layer

redirection

is

not

insigniﬁcant.

B. Understanding server selection strategy

第

14

页

共

26

页

The data center that provides most of the traffic is also the data center with

the smallest RTT for each dataset. That is true for 85% of cases.

RTT does play a role in the selection of YouTube servers.

However,

RTT

is

not

the

only

criteria

and

the

preferred

data

center

may

change over time.

the

fraction

of

traffic

served

by

non-preferred

data

centers

in

each

of

these

time slots is determined.

C. Mechanisms resulting in accesses to non-preferred data centers

A

ﬁrst

possibility

is

that

the

DNS

mechanisms

direct

a

request

to

the

non-preferred

data

center.

A

second

possibility

is

that

the

request

was

redirected to another data center by the preferred data center server.

3. Causes underlying access to non-preferred data centers

A.

Adaptive

DNS-level

load

balancing

mechanisms

are

in

place

during

the

high load period of traffic.

第

15

页

共

26

页

B. Variations across DNS servers in a network

a

DNS-level

assignment

policy

employed

by

YouTube,

probably

for

load

balancing

purposes,

which

can

vary

between

DNS

servers

and

thus

subnets

that belong to the same campus or ISP network

C. Investigating redirection at the application layer

1)Alleviating hot-spots due to popular videos:

DNS correctly

forwards the request to a server

in the preferred data center,

but since its load is too high, the server redirects part of the requests to another

server in a non-preferred data center.

Local and possibly persistent overload situations are handled by the YouTube

CDN via application-layer redirection mechanisms.

2)

Availability of unpopular videos:

when

the

videos

were

accessed

more

than

once,

only

the

ﬁrst

access

was

redirected to a non-preferred data center.

the

ﬁrst

access

to

an

unpopular

video

may

indeed

be

directed

to

a

non-preferred data center, but subsequent accesses are typically handled from

the preferred data center.

Downloads from non-preferred data centers can occur because of the limited

popularity of the videos. In particular, videos that are rarely accessed may be

unavailable

at

the

preferred

data

center

causing

the

user

requests

to

be

redirected to non-preferred data centers until the video is found.

第

16

页

共

26

页

4

YouTube

网站架构

（译稿

2

，

内容同第

1

章）

分类：

大规模系统架构

2009-01-11 15:38 587

人阅读

(0)

原贴

:http://lovelaozang.cn/show-6785-1.html

YouTube

的成长速度惊人，

目前每天视频访问量已达

1

亿，

但站点维护人员很少。

他们是如何管理，以实现如此强大供应能力的？被

Google

收购后，又在走什么样的

发展道路呢？

转载一些相关的文章，参考学习一下

原文

:

YouTube Architecture

YouTube

发展迅速，每天超过

1

亿的视频点击量，但只有很少人在维护站点和确保伸

缩性。

平台

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

第

17

页

共

26

页

处理飞速增长的流量

Java

代码

1.

while (true)

2.

{

3.

identify_and_fix_bottlenecks();

4.

drink();

5.

sleep();

6.

notice_new_bottleneck();

7.

}

[java]

view plaincopy

1.

while (true) { identify_and_fix_bottlenecks(); drink(); sleep(); notice_new_bottleneck(); }

每天运行该循环多次

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

，数据库里使用行级缓存

第

18

页

共

26

页

13

，缓存完整的

Python

对象

14

，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个

使用不当的策略。

应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不

了多少时间。只需弄一个代理来监听更改，预计算，然后发送。

视频服务

1

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

2

，每个视频由一个迷你集群来

host

，每个视频被超过一台机器持有

3

，使用一个集群意味着：

-

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

-failover

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

-

在线备份

4

，使用

lighttpd

作为

Web

服务器来提供视频服务：

-Apache

开销太大

-

使用

epoll

来等待多个

fds

-

从单进程配置转变为多进程配置来处理更多的连接

5

，大部分流行的内容移到

CDN

：

-CDN

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

-CDN

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

6

，不太流行的内容

(

每天

1-20

浏览次数

)

在许多

colo

站点使用

YouTube

服务器

-

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

-

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

-

调节

RAID

控制并注意其他低级问题

-

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

视频服务关键点

1

，保持简单和廉价

2

，保持简单网络路径，在内容和用户间不要有太多设备

3

，使用常用硬件，昂贵的硬件很难找到帮助文档

第

19

页

共

26

页

4

，使用简单而常见的工具，使用构建在

Linux

里或之上的大部分工具

5

，很好的处理随机查找

(SATA

，

tweaks)

缩略图服务

1

，做到高效令人惊奇的难

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

还有从

DBA Notes

看到过的一些：

一、系统主要用

Python

开发，用

psyco

提高性能

第

20

页

共

26

页

看到这个我总算知道

Google

为什么要收购

YouTube

了，都喜欢用

Python

嘛，本

来就有缘。用

Python

开发的速度显然比用

C/C++

、

Java

等高不少，这一点

eBay

就

比较传统，用

C++/Java

来写，结果落得需要几百个工程师，编译一次很久。最感兴

趣的是用了

psyco

这个东西，所说这玩意相当于

Java

中的

JIT

编译器，通常能将

Python

代码的执行速度提高

4

倍，对于算法集中的代码甚至能提高

10

到

100

倍。

二、使用

lighttpd

给视频内容本身提供服务时用了

lighttpd

，不能

Apache

，据说性能提高不少，

但有了说这个还不好，应该用

nginx

，俄罗斯人写的一玩意。

三、最流行的内容自己不管，放在

CDN

上

YouTube

很会享受，最常访问的内容自己的系统不管，放在运营商和

Google

（估

计是被

Google

收购之后吧？）的内容分发网络上。他们自己的服务器只要处理一些

不常访问的漏网之鱼就可以了，负载大大减轻。

四、缩略图是最大的问题，自己搞不定，最后用

Google

的

BigTable

搞定

俗话说人小鬼大绝对是有道理的，那么大的视频没什么问题，小小的缩略图却是

个大问题。原来

YouTube

的开发人员用

lighttpd

，发现效果不太好，就改了代码，但

效果还是不行。最后被

Google

收购后用了

BigTable

才算搞定这个问题。

五、

MySQL swap

问题，把

swap

关掉就行了

YouTube

用

MySQL

存元数据，

结果在

Linux

上

swap

颠簸很厉害，

解决的方法也简

单，把

swap

关掉就好了。而且人家胆子大，服务还在那里跑，这边就把它关了。

六、

MySQL

YouTube

用

MySQL

也是摸着石头过河，

一开始只用一个主服务器和

replication

，

显然过一阵子这个方法就不行了。后面他们尝试把视频和非视频业务分开处

理，但

这个方法也顶不了多久。最终还是走到数据分区这条正道上来。对数据库服务器的磁

盘系统的选择也很有意思，最早是用

10

块盘做

RAID 1+0

，但发现盘太多了也使不上

劲，所以后来改后一堆

RAID 1

。

5

YouTube

网站架构

（译稿

3

，

内容同第

1

章）

第

21

页

共

26

页

YouTube

发展迅速，每天超过

1

亿的视频点击量，但只有很少人在维护站点和确保伸

缩性。

平台

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

，处理飞速增长的流量。代码

while (true)

{ identify_and_fix_bottlenecks(); drink(); sleep();

notice_new_bottleneck(); }

每天运行该循环多次。

Web

服务器：

1

，

NetScaler

用于负载均衡和静态内容缓存

2

，使用

mod_fast_cgi

运行

Apache

3

，使用一个

Python

应用服务器来处理请求的路由

4

，应用服务器与多个数据库和其他信息源交互来获取数据和格式化

html

页面

5

，一般可以通过添加更多的机器来在

Web

层提高伸缩性

6

，

Python

的

Web

层代码通常不是性能瓶颈，大部分时间阻塞在

RPC

7

，

Python

允许快速而灵活的开发和部署

第

22

页

共

26

页

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 -

从单进程配置转变为多进程配置来处理更多的连接

第

23

页

共

26

页

5

，大部分流行的内容移到

CDN

：

-CDN

在多个地方备份内容，这样内容离用户更近的

机会就会更高

-CDN

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

颠簸

6

，不太流行的内容

(

每天

1-20

浏览次数

)

在许多

colo

站点使用

YouTube

服务器

-

长

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

-

在

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

-

调节

RAID

控制并注意其他低级问题

-

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

视频服务关键点：

1

，保持简单和廉价

2

，保持简单网络路径，在内容和用户间不要有太多设备

3

，使用常用硬件，昂贵的硬件很难找到帮助文档

4

，使用简单而常见的工具，使用构建在

Linux

里或之上的大部分工具

5

，很好的处理随机查找

(SATA

，

tweaks)

缩略图服务：

1

，做到高效令人惊奇的难

2

，每个视频大概

4

张缩略图，所以缩略图比视频多很多

3

，缩略图仅仅

host

在几个机器上

第

24

页

共

26

页

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

，早期

-

使用

MySQL

来存储元数据，如用户，