优酷网架构学习笔记

21CTO

资讯 0 4209 2017-02-26 12:00:45

介绍过视频老大YouTube的技术架构，相信大家看了都会有不少的感触。优酷在国内也算是视频网站中的姣姣者，它的架构相对于YouTube是怎么样的，本文介绍的一部分架构内容，希望对大家有用。

一基本数据

据大数据统计，优酷网目前日均独立访问人数（UV）达到了1亿+，日均访问量（PV）接近20亿，全球网站排名217名，国内网站排名49名。

优酷最开始使用的服务器主要为Dell PowerEdge 1950/860，存储阵列以Dell MD1000为主。到目前为止，优酷网至少有6000多台服务器遍布在国内各大省市节点。

二前端框架

从一开始，优酷使用LAMP架构构建了CMS，用于解决前端页面显示。其各个模块之间抽象分离较恰当，可扩展性很好，做到了UI可分离，让开发与维护变得简单&灵活。

那么，优酷前端模块调用关系是什么样子的呢？来看下图：

根据module、method及params来确定路由调用相对应模块，显得很简洁。下面是优酷的前端局部架构图：

三数据库之结构

优酷数据库的架构也是经历了一系列的迭代更新。

从一开始的单台MySQL服务器到简单的MySQL主从复制、SSD 优化、垂直分库、水平sharding 分库。

这一系列过程只有经历过才会有更深的体会。与Youtube的架构经历一样，架构也是一步步慢慢成长成熟。

1 MySQL主从复制:

MySQL的主从复制实现数据库的读写分离，很好的提升了读性能。其原理如下图：

其主从复制的过程如下图所示：

主从复制机制，也会带来其他一系列性能瓶颈问题。比如：

]写入无法扩展[/

]写入无法缓存[/

]复制延时[/

]锁表率上升[/

]表变大，缓存率下降[/

问题产生了总得解决，于是音阶产生了如下的优化方案。

2、MySQL垂直分区

如果把业务切割得足够独立，那把不同业务的数据放到不同的数据库服务器将是一个不错的方案，而且万一其中一个业务崩溃了也不会影响其他业务的正常进行，并且也起到了负载分流的作用，大大提升了数据库的吞吐能力。经过垂直分区后的数据库架构图如下：

然而，尽管业务之间已经足够独立了，但是有些业务之间或多或少总会有点联系，如用户，基本上都会和每个业务相关联，况且这种分区方式，也不能解决单张表数据量暴涨的问题，因此为何不试试水平sharding呢？

3、MySQL水平分片（Sharding）

这是一个非常好的思路，将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可，原理图如下：

如何来确定某个用户所在的shard呢，可以建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，如下图所示：

优酷如何解决跨shard的查询呢？这个是个难点，据了解优酷尽量不跨shard查询，实在不行通过多维分片索引、分布式搜索引擎，下策是分布式数据库查询（这个将非常麻烦而且损耗性能）。

四缓存策略

所有大型网站系统都对“缓存”情有独钟。从HTTP缓存到memcached内存数据库缓存，优酷在此时并没有使用内存缓存。理由如下：

]避免内存复制，内存颠簸，避免内存锁[/

]如接到老大哥通知要把某个视频撤下来，如果在缓存里是比较麻烦的[/

而且Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也较低下。

另外，和Youtubde一样，访问优酷的保持流畅，归功于自建了完善的CDN网络（内容分发网络），通过多种方式保证分布在全国各地的用户就近访问。

比如用户点击视频播放请求后，优酷将根据用户所处地区位置，把离用户最近、服务状况最好的视频服务器或缓存服务器地址传送给用户，从而保证可以得到最佳的视频体验。