[转]大型网站架构之优酷篇
大型网站架构之优酷篇[转]
首先列出了网站架构关注的一些要点，包括：
* 在线升级
* 效率
* 核心简单
* 独立性
* 模块化
再播报一组优酷的数据：
* 用户数：4000万
* 视频数：2000万
* PV：1.3亿
* VV：1.6亿
主要采用的也都是一些非常常见，成熟的软件和操作系统
包括：centos／LVS／PHP
采用简单的方式对URL进行规划：
http://domain/modules/method/params/
举例：
http://www.youku.com/playlist_showlist/t2d1c123.html 资讯频道的豆单列表页面
http://www.youku.com/playlist_show/id_3219807.html 某个豆单的浏览页面
http://v.youku.com/v_playlist/f3220308o1p0.html 豆单中某个视频的播放页面
优酷每周规定周二固定时间进行发布（这样可以简化一些发布上线的流程）
通过自建的CMS解决了大部分的页面的内容维护和生成的问题。
缓存的设计
缓存黄金原则：让数据更靠近 CPU 。
CPU-->CPU 一级缓存-->二级缓存-->内存-->硬盘-->LAN-->WAN
讲到了 Youku 自己的内部项目，针对大文件缓存的。
目前开源软件中，Squid 的 write() 用户进程空间有消耗，（这个需要看源码才能看到）
Lighttpd1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。
Youku不用内存做缓存(避免内存拷贝，避免内存锁)。（优酷应该也用了不少memcached）
值得注意的是，缓存技术容易被滥用，也有副作用，比如接到老大通知要把某个视频撤下来，如果在缓存里是比较麻烦的。
MySQL数据库的优化
曾经也考虑过使用数据库中间层来解决数据库的问题，但是考虑的方案比较复杂不够简单，所以放弃。（简单最重要）
数据库采用水平扩展，主从复制，随着从数据库的增多，复制延迟越来越厉害，最终无法忍受。
最终还是采用数据库的sharding，把一组用户相关的表和数据放到一组数据库上。
使用SSD来优化mysql的I／O，性能提升明显，每块16G，6块SSD做RAID。
数据库的类型选用MYISAM
数据库的拆分策略，先纵向按照业务或者模块拆分。对于一些特别大的表，再采用垂直拆分
根据用户进行分片，尽可能不要跨篇查询。如果确实要跨片查询，可以考虑搜索的方案，先索引再搜索。
分布式的数据库方案太复杂，否掉。
网络服务器优化
如果要优化服务器的性能，必须对Libevent 非常熟悉，因为常见的memcached／squid／lighttpd等都有用到。确实很重要。
libevent封装了epoll/kqueue
视频的去重方案：md5和视频指纹。
关键的业务要自己来做。
首先列出了网站架构关注的一些要点，包括：
* 在线升级
* 效率
* 核心简单
* 独立性
* 模块化
再播报一组优酷的数据：
* 用户数：4000万
* 视频数：2000万
* PV：1.3亿
* VV：1.6亿
主要采用的也都是一些非常常见，成熟的软件和操作系统
包括：centos／LVS／PHP
采用简单的方式对URL进行规划：
http://domain/modules/method/params/
举例：
http://www.youku.com/playlist_showlist/t2d1c123.html 资讯频道的豆单列表页面
http://www.youku.com/playlist_show/id_3219807.html 某个豆单的浏览页面
http://v.youku.com/v_playlist/f3220308o1p0.html 豆单中某个视频的播放页面
优酷每周规定周二固定时间进行发布（这样可以简化一些发布上线的流程）
通过自建的CMS解决了大部分的页面的内容维护和生成的问题。
缓存的设计
缓存黄金原则：让数据更靠近 CPU 。
CPU-->CPU 一级缓存-->二级缓存-->内存-->硬盘-->LAN-->WAN
讲到了 Youku 自己的内部项目，针对大文件缓存的。
目前开源软件中，Squid 的 write() 用户进程空间有消耗，（这个需要看源码才能看到）
Lighttpd1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。
Youku不用内存做缓存(避免内存拷贝，避免内存锁)。（优酷应该也用了不少memcached）
值得注意的是，缓存技术容易被滥用，也有副作用，比如接到老大通知要把某个视频撤下来，如果在缓存里是比较麻烦的。
MySQL数据库的优化
曾经也考虑过使用数据库中间层来解决数据库的问题，但是考虑的方案比较复杂不够简单，所以放弃。（简单最重要）
数据库采用水平扩展，主从复制，随着从数据库的增多，复制延迟越来越厉害，最终无法忍受。
最终还是采用数据库的sharding，把一组用户相关的表和数据放到一组数据库上。
使用SSD来优化mysql的I／O，性能提升明显，每块16G，6块SSD做RAID。
数据库的类型选用MYISAM
数据库的拆分策略，先纵向按照业务或者模块拆分。对于一些特别大的表，再采用垂直拆分
根据用户进行分片，尽可能不要跨篇查询。如果确实要跨片查询，可以考虑搜索的方案，先索引再搜索。
分布式的数据库方案太复杂，否掉。
网络服务器优化
如果要优化服务器的性能，必须对Libevent 非常熟悉，因为常见的memcached／squid／lighttpd等都有用到。确实很重要。
libevent封装了epoll/kqueue
视频的去重方案：md5和视频指纹。
关键的业务要自己来做。
