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

下载

下载

16积分

20积分

下载

20积分

VIP价：16积分

Web网站架构案例分析从优酷网浅谈大型网站的架构和优化邱丹qiudan@ 北京 议程架构和环境Web架构的8个特性优酷网案例网络优化 Part I架构和环境适应天上飞翔：鸟拥有翅膀适应水里呼吸：鱼拥有鳃 通用架构的梦想愿景：让拥有鳃和翅膀的人, 能够适应各种环境 结果：被具体环境退化或替换 架构的进化和退化进化原理-寻找最适合的退化原理-简化不必要的 架构师的职责初始环境while(true){寻找适应环境的结构; /*进化*/简化结构;/*退化*/环境改变;} Part II Web环境下架构8个特性可扩展(Scalability)在线升级效率可靠性可理解简单核心独立性模块化 Part III 网站架构案例关于优酷网()-中国大陆领先的在线视频网站 网站规模(08年9月)万VV: 亿+20000日上传视频: 6万+150001000050000VV(播放数)/日PV/日Source: iUserTracker2008年9月 网站核心业务带来的架构特性可扩展(Scalability)在线升级效率可靠性可理解√简单核心√独立性模块化 创世纪：网站的初始环境2006年下半年500家视频网站存在，但规模都不大部分互联网用户关注巨大的用户潜力 拥抱开源世界 前端框架Browser :http://www..com/<module>/<method>/[params] Front Framework:hook(request){module, method, params< = ->method(params)echo reponse}:method1(params){return “<p>hello, world!</p>”} 简单前端框架满足的特性模块分离，多人开发可扩展√(Scalability)无状态：前端可扩展在线升级√分层，UI分离效率可靠性√没有采用第三方Web框架可理解√√自建CMS解决掉大部分页简单核心面显示√√独立性√模块化√ CMS前端架构(局部) 从最简单开始能run就行时间：1个月功能：核心功能apachephpMySQL: 1单点搜索引擎：无中间层：无 架构进化访问量迅速增加，如何进化?改进策略：增加缓存 缓存黄金原则：local, local ,local如何让数据更靠近CPU?让少部分常用数据就近存起来CPU一级缓存CPU二级缓存内存缓存数据空闲槽硬盘LANWAN数据仅供参考 HTTP缓存–Squid/VarnishBrowserBrowserCacheCaapacheappaacchheHaTcThPeepRreovxeyrsepphhpProxyphppHTTP Response:Cache-Control: max-age=3600, must-revalidateExpires: Fri, 28 Oct 2007 14:19:41 GMTLast-Modified: Mon, 27 Jun 2007 05:21:17 GMT 分布式内存key-value缓存CMacehmecachedBrowserproxyBrowserCacheCaapacheappaacchheCaacchheeeppprrooxxyyphhpphppMemcached协议：存：set key10 0 3\r\nfoo\r\n\-->STORED\r\n取：get key1\r\n -->VALUE key1 0 3\r\nfoo\r\nEND\r\n 大文件缓存(内部项目)Squid问题write()，用户进程空间消耗 缓存满足的特性如果数据可缓存，效率增可扩展√√长明显(Scalability)在线升级√扩展性效率√缓存命中率直接影响效率可靠性√√缓存技术容易被滥用可理解√√简单核心√√√独立性√模块化√ 新的问题？数据库成为性能瓶颈CMacehmecachedBrowserproxyBrowserCacheCaCaapacheappaacheacchheechepprrooxxyypphphphpp 扩展中间层or 扩展数据库VS MySQLReplicationaapacappachheacheepphphphppwrite主/从复制read cluster MySQL主/从复制过程UPDATE t1...INSERT t2...ALTER t1...binary log100...101UPDATE t1...主库102INSERT t2...103ALTER t1...104...tcp长连接relay log100...I/O thread101UPDATE t1...UPDATE t1...102INSERT t2...丛库INSERT t2...ALTER t1...103ALTER t1...SQL thread104... 数据复制带来的特性读扩展–可扩展√√√适合读多写少的业务(Scalability)在线升级可靠性√效率简单√可靠性复制延时< √√√可理解√√简单核心√√√√并非万灵金丹独立性√复制延时恶化模块化√ MySQL复制问题–无法写扩展写入无法扩展aappaacchhe写入无法缓存apacheepph复制延时phphpp100 write100w锁表率上升表变大，缓存率下降1000 readread cluster100w100w100w100w250r250r250r250r 现在该如何进化?MySQLProxy/HSCALE?lighttpd同一作者，进度受限。lua中间层，性能/可维护性/成熟度？MySQL分区技术?无法进行跨服务器分区。MySQL集群(MySQLNDBCluster) ?厚重的瑞士军刀，层面过多，性能/复杂度？没有银弹方案。? SSD优化MySQL某单台MySQL服务器(intel-4core,16G, ssd)单表8000万rows1000+连接/秒iowait< 1% DB写入拆分aappaacheapacchheepphpphhppread clusterread cluster DB垂直分区Part 1Part 2Part 3其他用户消息其他用户消息joinjoin DB水平分片(Sharding)Shard 1其他用户其他用户消息消息Shard 2其他按用户user_id分片消息 分片定位(1) 获取user 103的messagesShard 1aaapppaaacchchheeepphpphhpp(2) user 103在哪?(3) shard 2ShardingManagerShard 2目录User_IDShard_ID101110211032 Shard群的分组管理Server1Server2shard_db1shard_db3shard1shard2shard3shard7shard8shard9shard_db2shard_db4shard4shard5shard6shard10shard11shard12 如何处理跨shard的查询?上策：不面对中策：多维分片索引、分布式搜索引擎下策：分布式数据库查询 良好的扩展性CMacehmecachedBrowserproxyBrowserCacheCaCaappacheapaacheacchheechepprrooxxyypphhpphpp 分区带来的特性分区并非必要可扩展增加管理复杂度√√√√(Scalability)在线升级√效率√可靠性√√√√可理解√√√简单核心√√√√独立性√模块化√ Part IV 网络吞吐量优化吞吐量同响应速度的不同进程切换开销保持当前cpu寄存器(eax,ebx,esi,edi,...)恢复新进程cpu寄存器(eax,ebx,esi,edi,...)jmpnew_eipfork/pthread问题大量进程切换开销寄存器越多效率越低用vmstat查看csApache prefork和MySQL的pthread大量进程切换开销过大 事件驱动select()问题1024限制位扫描poll()问题从内核到用户进程拷贝描述符数组epoll(kernel +)采用mmap()避免内核到用户进程的拷贝libevent封装epoll/kqueueepoll推动当今Webmemcached/lighttpd/nginx/squid/haproxy 案例：Memcached连接问题PHP对memcached的tcp连接开销静态Hash扩展不方便 本地Memcachedagent(内部项目)基于libevent(封装epoll)memcached兼容接口本地unixdomain socket对Memcached长连接Memcached动态任意扩展(Consistent hashing)phpphpmemcachedunixdomain socketagenmemcachedttcp连接池 Q & A 谢谢！