从优酷网浅谈大型网站的架构和优化

Web网站架构案例分析从优酷网浅谈大型网站的架构和优化QCon2009北京邱丹[e-mail]议程架构和环境Web架构的8个特性优酷网案例网络优化PartI架构和环境适应天上飞翔：鸟拥有翅膀适应水里呼吸：鱼拥有鳃通用架构的梦想愿景：让拥有鳃和翅膀的人,能够适应各种环境结果：被具体环境退化或替换架构的进化和退化进化原理-寻找最适合的退化原理-简化不必要的架构师的职责初始环境while(true){寻找适应环境的结构;/*进化*/简化结构;/*退化*/环境改变;}PartIIWeb环境下架构8个特性可扩展(Scalability)在线升级效率可靠性可理解简单核心独立性模块化PartIII网站架构案例-中国大陆领先的在线视频网站关于优酷网(youku.com)05000100001500020000网站规模(08年9月)VV(播放数)/日PV/日万Source:iUserTracker2008年9月VV:1.6亿+日上传视频:6万+网站核心业务带来的架构特性可扩展(Scalability)在线升级效率可靠性可理解√简单核心√独立性模块化创世纪：网站的初始环境2006年下半年500家视频网站存在，但规模都不大部分互联网用户关注巨大的用户潜力拥抱开源世界前端框架Browser:[params]FrontFramework:hook(request){module,method,params--request.urlresponse=module.php-method(params)echoreponse}module1.php:method1(params){return“phello,world!/p”}简单前端框架满足的特性模块分离，多人开发无状态：前端可扩展分层，UI分离没有采用第三方Web框架自建CMS解决掉大部分页面显示可扩展(Scalability)√在线升级√效率可靠性√可理解√√简单核心√√独立性√模块化√CMS前端架构(局部)从最简单开始apachephp能run就行时间：1个月功能：核心功能MySQL:1单点搜索引擎：无中间层：无架构进化访问量迅速增加，如何进化?改进策略：增加缓存缓存黄金原则：local,local,localCPU一级缓存CPU二级缓存内存硬盘LANWAN如何让数据更靠近CPU?让少部分常用数据就近存起来缓存数据空闲槽数据仅供参考BrowserHTTP缓存–Squid/VarnishCacheproxyHTTPReverseProxyBrowserCacheapachephpapachephpapachephpHTTPResponse:Cache-Control:max-age=3600,must-revalidateExpires:Fri,28Oct200714:19:41GMTLast-Modified:Mon,27Jun200705:21:17GMT分布式内存key-value缓存BrowserCacheproxyCacheproxyBrowserCacheapachephpapachephpapachephpCacheproxyMemcachedMemcached协议：存：setkey1003\r\nfoo\r\n\--STORED\r\n取：getkey1\r\n--VALUEkey103\r\nfoo\r\nEND\r\n大文件缓存(内部项目)Squid问题write()，用户进程空间消耗lighttpd1.5/AIO问题AIO读取文件到用户内存导致效率低下Sendfile()ZeroCopy直接发送文件到网卡接口不用内存做缓存避免内存拷贝避免锁缓存满足的特性如果数据可缓存，效率增长明显扩展性缓存命中率直接影响效率缓存技术容易被滥用可扩展(Scalability)√√在线升级√效率√可靠性√√可理解√√简单核心√√√独立性√模块化√新的问题？数据库成为性能瓶颈BrowserCacheproxyCacheproxyBrowserCacheapachephpapachephpapachephpCacheproxyMemcached扩展中间层or扩展数据库VSreadclusterMySQLReplicationapachephpapachephpapachephpwrite主/从复制MySQL主/从复制过程主库丛库100...101UPDATEt1...102INSERTt2...103ALTERt1...104...UPDATEt1...INSERTt2...ALTERt1...I/OthreadSQLthreadbinarylog100...101UPDATEt1...102INSERTt2...103ALTERt1...104...relaylogUPDATEt1...INSERTt2...ALTERt1...tcp长连接数据复制带来的特性读扩展–适合读多写少的业务可靠性简单复制延时0.1s并非万灵金丹复制延时恶化可扩展(Scalability)√√√在线升级√效率√可靠性√√√可理解√√简单核心√√√√独立性√模块化√MySQL复制问题–无法写扩展readcluster100w100w250r100w250r100w250r100write100w250rapachephpapachephpapachephp1000read写入无法扩展写入无法缓存复制延时锁表率上升表变大，缓存率下降现在该如何进化?MySQLProxy/HSCALE?lighttpd同一作者，进度受限。lua中间层，性能/可维护性/成熟度？MySQL分区技术?无法进行跨服务器分区。MySQL集群(MySQLNDBCluster)?厚重的瑞士军刀，层面过多，性能/复杂度？没有银弹方案。?SSD优化MySQL某单台MySQL服务器(intel-4core,16G,ssd)单表8000万rows1000+连接/秒iowait1%readclusterDB写入拆分readclusterapachephpapachephpapachephpDB垂直分区Part1Part2Part3其他消息用户其他消息用户joinjoinDB水平分片(Sharding)其他消息用户其他用户消息其他用户消息Shard1Shard2按user_id分片分片定位apachephpapachephpapachephpShardingManagerUser_IDShard_ID101110211032目录Shard1Shard2(1)获取user103的messages(2)user103在哪?(3)shard2Shard群的分组管理Server1shard_db1shard1shard2shard3shard_db2shard4shard5shard6Server2shard_db3shard7shard8shard9shard_db4shard10shard11shard12如何处理跨shard的查询?上策：不面对中策：多维分片索引、分布式搜索引擎下策：分布式数据库查询良好的扩展性BrowserCacheproxyCacheproxyBrowserCacheapachephpapachephpapachephpCacheproxyMemcached分区带来的特性分区并非必要增加管理复杂度可扩展(Scalability)√√√√在线升级√效率√可靠性√√√√可理解√√√简单核心√√√√独立性√模块化√PartIV网络吞吐量优化吞吐量同响应速度的不同进程切换开销保持当前cpu寄存器(eax,ebx,esi,edi,...)恢复新进程cpu寄存器(eax,ebx,esi,edi,...)jmpnew_eipfork/pthread问题大量进程切换开销寄存器越多效率越低用vmstat查看csApacheprefork和MySQL的pthread大量进程切换开销过大事件驱动select()问题1024限制位扫描poll()问题从内核到用户进程拷贝描述符数组epoll(kernel2.6+)采用mmap()避免内核到用户进程的拷贝libevent封装epoll/kqueueepoll推动当今Webmemcached/lighttpd/nginx/squid/haproxy案例：Memcached连接问题PHP对memcached的tcp连接开销静态Hash扩展不方便本地Memcachedagent(内部项目)基于libevent(封装epoll)memcached兼容接口本地unixdomainsocket对Memcached长连接Memcached动态任意扩展(Consistenthashing)agentmemcachedphpphptcp连接池unixdomainsocketmemcachedQ&A谢谢！