互联网应用服务扩展的一点经验-- 以FreeWheel 核心系统演化为例<br />王迪 Di Wang<br />dwang@freewheel.tv<br />MSN: wangdieda@hotmail.com<br />
议程<br />我们的主要工作<br />FreeWheel MRM系统架构<br />过去三年的服务扩展实践<br />应用服务扩展实践<br />数据扩展实践<br />运营原则<br />关于FreeWheel<br />
我们的主要工作<br /><ul><li>当一段客户视频在某媒体播放时,我们动态决策…</li></ul>哪些广告商具有销售权?<br />哪些创意最适合当前投放?<br />如何满足用户体验、内容限制、排他性等约束要求?<br />产业链各商...
为什么做这件事—why?<br />广告是在线视频的主要盈利方式<br />版权保护是视频行业的核心问题 (尤其在美国)<br />传统媒体商拥有优质内容和广告资源,缺少传播渠道 – 供给<br />视频网站拥有流量,需要内容吸引用户,以广告盈...
产品服务Monetization Rights Management – MRM<br />Syndication Video Economy<br />TV Everywhere<br />
产品应用示例<br />
如何实现?——互联网广告服务系统组成<br />Web前端——B2B应用, Ruby on Rails<br />后台核心系统<br />广告服务器: 高性能/高可靠 分布集群,C++/Python/Lua<br />日志收集处理分析ETL: ...
FreeWheel MRM系统整体架构<br />
需求难点分析<br />商业模式决定设计方案:<br />互联网服务的规模经济和沉淀成本<br />流量价值高于扩展成本才有意义,运营成本往往占一半以上!<br />云计算 vs自运营的选择<br />B2B与B2C的不同:<br />Web ...
我们的一些经验和原则<br />应用服务扩展<br />无状态应用服务器<br />复制与多层次Cache<br />数据仓库扩展<br />De-normalization/Pivot<br />Roll up/Data Availabili...
无状态广告服务器<br />Embed Lighttpd: 消除fastcgi进程间网络通信,方便部署。<br />交易状态相关信息编码URL,消除服务器间通信依赖。<br />例如:<br />http://bd0dc.v.fwmrm.net...
无状态应用服务器 (Case Demo)<br />服务器间信息交换,通过定时反馈同步<br />应用服务重启/运行不依赖于其他应用程序<br />Load Balancer<br />Ads1<br />Ads2<br />AdsN<br /...
复制与多层次Cache<br />广告服务器的核心功能:将OLTP中用户预定的广告定位条件与当前视频请求做最佳匹配。<br />满足性能和高可用要求,实现了四点cache机制:<br />Pusher Regular Push<br />Qui...
Regular Push<br />Why<br />分离数据库变动对广告服务器的影响,减少直接数据库访问<br />What<br />每个数据中心一台Slave,运行一个Pusher,Pull from DB,预处理和数据准备,<br />...
Quick Push<br />Why<br />部分服务数据对时效性要求高,要求更新小于半小时。<br />What<br />Pusher 单独生成只包含时效敏感数据的小mmap, 每隔15分钟生成并同步到各服务器一次, 400 Mb/Du...
Memcache<br />Why<br />为响应实时直播视频信息快速上传同步和广告服务的要求<br />What<br />收到服务请求,内存查找<br />If 命中,请求返回<br />Else 查找memcache<br />If c...
Ad Request come in.<br />Look up video from RAM.<br />3".  Video in mem, return response<br />3.  Video not it mem, redire...
Dot Server<br />Why<br />Adserver高可用性保护方案以应对突发峰值和Bug down机.<br />触发Down机的bug往往会中断全部应用服务器<br />What<br />服务器内维持一个待服务请求队列, 当...
无状态日志处理<br />日志处理设计的主要考虑因素:<br />减少日志体积,容易扩展,避免自己定义格式和写Parser<br />Text Log -> Binary log by Google Protocol buffer<br />用...
日志格式变化<br />Protocol Buffer Binarylog:<br />advertisement {<br />ad_id: 29:121 <br />ad_replica_id: 0 <br />rendition_id: ...
现成Parser
存储更小</li></li></ul><li>数据仓库扩展<br />易于查询和建模:Normalization vs De-normalization<br />优化行数:<br />Pivot<br />Long tail roll up ...
Normalization<br />优点:<br />Fact 表精简,数据无冗余<br />缺点:<br />当业务逻辑复杂时,查询可能变得很复杂,需多次Join。<br />当需要按照某个dimension ID做Group by时不能有...
De-Normalization<br />优点:<br />Star Schema,将复杂逻辑放到外部程序,而使得SQL逻辑简单,fact表不增加行,查询性能较好。<br />标准BI工具建模容易。<br />缺点:<br />Fact表增加...
Pivot<br />优点:<br />通过转秩(Pivot),使原来分布在fact表中相同Key组合的多行数据合并到一行,减少了行数,使SQL更加简单,提高查询性能。在大数据量时收益明显。<br />缺点:<br />fact表单条记录增加了...
Long tail roll up & Data Availability<br />一个简单的计算: 100,000 video X 100 site X 100 Country X 1,000 Ad = 1,000,000,000,000 ...
Benchmarking与查询优化<br />自动Benchmark所有查询<br />使用Production数据<br />自动check out SQL运行<br />提取MySQL Slow Query log测量值,多次测量平均<br...
Benchmarking (Case Demo)<br />Internal Benchmark Tool<br />Benchmark Report w queries run longer than 10 min<br />
Partition and Sharding<br />做完上述优化以后的选择<br />Table Partition: <br />选择event_date作为Key<br />以Partition为单位增、删数据仓库表,几乎不用Updat...
DB Volume Increase Trendline Before Sharding<br />29<br />
Problem<br />Database<br />1.1T<br />1.1T<br />Swap<br />Read<br />Write<br /><ul><li>Bad query performance!
Impossible to do migration and reprocess!
Hard to scale!</li></ul>30<br />
Sharding  Architecture <br />31<br />Client Facing End <br />Shard 2<br />Shard 3<br />Shard 1<br />   Huge DB<br />
基于Sharding下的ETL流程演示<br />32<br />Client Facing End <br /> 服务中<br />X<br />X<br />X<br />X<br />X<br />X<br /> 脱离服务<br />加载...
运营原则——50% 上限 & N+1 Data Center<br />所有子系统做容量扩展规划时,预估上限以50%负载(经验值)为限。<br />Adserver为峰值预留50%容量,e.g突发新闻,世界杯决赛<br />后台日志处理在用户要...
监控与响应<br />监控分类:<br />应用服务Check Live<br />服务异常警报:错误,延时等<br />数据库Master-Slave同步<br />Cache有效性:Quick Push<br />端到端数据一致性检验:模拟...
示例:应用服务Check Live日报<br />示例:数据一致性监控报警<br />
多阶段部署<br />正式上线前Staging部署<br />一个按比例构建的模拟生产环境,包括所有类型应用服务<br />拓扑结构与生产环境相同<br />使用生产环境的数据库数据和真实用户请求采用模拟<br />可充当集成测试环境<br /...
关于测试的一点话题<br />以自动化回归测试为核心<br />并未使用TDD单元测试<br />坚持Local测试->集成测试->回归测试->Staging<br />每次升级发布前的测试检查清单<br />New Feature Funct...
关于测试(回归测试系统 Demo)<br />
系统演化路线图<br />第一阶段:2007年12月 – 2008年6月 <br />目标:上线,验证服务可用性<br />扩展工作:Push/Quick Push,监控,日志处理架构<br />集群规模:20台广告服务器,4ETL, 4 预测...
当前运营情况<br />第三阶段:2009年10月--至今<br />目标:支持大客户,运营友好<br />扩展工作:DB Sharding,Dot Server, 多阶段部署<br />集群规模:<br />广告服务器:60台,日均服务视频广...
2009.5-2010.3间流量增长20倍!<br />服务流量趋势和可用性<br />Service Level Agreement (SLA) >= 99.99%<br />
关于分布式系统和Web服务扩展相关链接<br />Blogs<br />NatiShalom's Blog: Discussions about middleware and distributed technologieshttp://nat...
Presentations<br />Scalable Internet Architectureshttp://www.slideshare.net/shiflett/scalable-internet-architectures<br />...
Upcoming SlideShare
Loading in …5
×

大规模数据处理

2,144 views
2,053 views

Published on

1 Comment
4 Likes
Statistics
Notes
  • 双击的技术
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,144
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
64
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

大规模数据处理

  1. 1. 互联网应用服务扩展的一点经验-- 以FreeWheel 核心系统演化为例<br />王迪 Di Wang<br />dwang@freewheel.tv<br />MSN: wangdieda@hotmail.com<br />
  2. 2. 议程<br />我们的主要工作<br />FreeWheel MRM系统架构<br />过去三年的服务扩展实践<br />应用服务扩展实践<br />数据扩展实践<br />运营原则<br />关于FreeWheel<br />
  3. 3. 我们的主要工作<br /><ul><li>当一段客户视频在某媒体播放时,我们动态决策…</li></ul>哪些广告商具有销售权?<br />哪些创意最适合当前投放?<br />如何满足用户体验、内容限制、排他性等约束要求?<br />产业链各商业伙伴能分享多少广告收入?<br /><ul><li>投放报表/分析</li></ul>哪些广告在哪些Video/Site上产生多少投放、点击、独立用户?<br /><ul><li> 投放和存量预测</li></ul>每个广告未来90天可能的投放量<br />各媒体产品未来90可能的广告量<br />例子: CNN News on YouTube<br />
  4. 4. 为什么做这件事—why?<br />广告是在线视频的主要盈利方式<br />版权保护是视频行业的核心问题 (尤其在美国)<br />传统媒体商拥有优质内容和广告资源,缺少传播渠道 – 供给<br />视频网站拥有流量,需要内容吸引用户,以广告盈利 – 需求<br />FW作为独立第三方应用服务有效调剂需求与供给,提供客观测量,可为用户挖掘更多视频广告价值。<br />美国视频广告市场价值10亿美元<br />来源: IAB Internet Advertising Report 2009<br />国内视频广告市场价值14亿人民币<br />来源: iResearch 2010.04 Summit<br />
  5. 5. 产品服务Monetization Rights Management – MRM<br />Syndication Video Economy<br />TV Everywhere<br />
  6. 6. 产品应用示例<br />
  7. 7. 如何实现?——互联网广告服务系统组成<br />Web前端——B2B应用, Ruby on Rails<br />后台核心系统<br />广告服务器: 高性能/高可靠 分布集群,C++/Python/Lua<br />日志收集处理分析ETL: 高吞吐量/及时, C++/Python<br />预测系统: 高吞吐量/运算密集/支持多并发, Erlang/C++<br />视频播放整合<br />Flash SDK<br />Silverlight SDK<br />Javascript SDK<br />iPhone/iPad app<br />…<br />
  8. 8. FreeWheel MRM系统整体架构<br />
  9. 9. 需求难点分析<br />商业模式决定设计方案:<br />互联网服务的规模经济和沉淀成本<br />流量价值高于扩展成本才有意义,运营成本往往占一半以上!<br />云计算 vs自运营的选择<br />B2B与B2C的不同:<br />Web UI访问较少,后台服务压力较大<br />商业逻辑复杂:亿级用户访问,数百万video/page,数十万广告创意,数万内容公司,数千家视频网站的广告选择匹配。<br />服务的高可靠性:99.99% uptime,<300ms latency<br />峰值比预留:5:1 Peak to Mean.<br />数据驱动为中心:完整性,实时性,多用户隔离,可扩展<br />商业客户议价能力强,需大量服务支持工具。<br />
  10. 10. 我们的一些经验和原则<br />应用服务扩展<br />无状态应用服务器<br />复制与多层次Cache<br />数据仓库扩展<br />De-normalization/Pivot<br />Roll up/Data Availability<br />Benchmarking与查询优化<br />Split-Loading/Sharding<br />运营原则<br />50% 运行负载上限 & N+1 Data Center<br />监控与响应<br />多阶段部署<br />
  11. 11. 无状态广告服务器<br />Embed Lighttpd: 消除fastcgi进程间网络通信,方便部署。<br />交易状态相关信息编码URL,消除服务器间通信依赖。<br />例如:<br />http://bd0dc.v.fwmrm.net/ad/l/1?last=1&metr=127&s=b004&t=12736523773101485&adid=145307&arid=0&reid=70701&auid=&cn=defaultImpression&et=i&_cc=145307,70701,,,1273652377,1&tpos=0&iw=&uxnw=&uxss=&uxct=&init=0&cr=<br />s – 服务器ID<br />t – 交易GUID<br />adid – 广告ID<br />
  12. 12. 无状态应用服务器 (Case Demo)<br />服务器间信息交换,通过定时反馈同步<br />应用服务重启/运行不依赖于其他应用程序<br />Load Balancer<br />Ads1<br />Ads2<br />AdsN<br />…….<br />Log<br />Log<br />Log<br />Feedback<br />Backend<br />
  13. 13. 复制与多层次Cache<br />广告服务器的核心功能:将OLTP中用户预定的广告定位条件与当前视频请求做最佳匹配。<br />满足性能和高可用要求,实现了四点cache机制:<br />Pusher Regular Push<br />Quick Push<br />Memcache<br />Dot Server<br />
  14. 14. Regular Push<br />Why<br />分离数据库变动对广告服务器的影响,减少直接数据库访问<br />What<br />每个数据中心一台Slave,运行一个Pusher,Pull from DB,预处理和数据准备,<br />“mmap” structured memory dump。<br />Read DB->Prep Data->Dump Repo->Sync Repo-> Reload Repo->Switch<br />Gen/Sync twice per hour,2.9 G/Dump<br />Master->Slave读写分离复制需要注意的方面<br />避免Master“长”写锁block Slave读锁<br />减少用trigger和procedure实现业务逻辑<br />
  15. 15. Quick Push<br />Why<br />部分服务数据对时效性要求高,要求更新小于半小时。<br />What<br />Pusher 单独生成只包含时效敏感数据的小mmap, 每隔15分钟生成并同步到各服务器一次, 400 Mb/Dump。<br />需要调度与正常Push错峰带宽使用<br />
  16. 16. Memcache<br />Why<br />为响应实时直播视频信息快速上传同步和广告服务的要求<br />What<br />收到服务请求,内存查找<br />If 命中,请求返回<br />Else 查找memcache<br />If cache命中,请求返回;同时item添加到内存中<br />Else if cache正在被创建,返回。<br />Else cache内容缺失,返回;启动异步OLTP查找<br />If DB命中,item同时添加到cache和内存中<br />Else DB缺失,item placeholder添加到cache中,设置过期<br />
  17. 17. Ad Request come in.<br />Look up video from RAM.<br />3".  Video in mem, return response<br />3.  Video not it mem, redirect to /ax/ interface<br />Async look up video from cache.<br />5,6: Query memcached for Video. the result might be:<br />   a).NULL,   b). Hit but data is loading by some adserver   c). Hit and data available<br />7". Return response.<br />7.  if cache missing, then return.<br />8. Set Video with status = loading<br />9. Invoke a thread fetch video from oltp DB.<br />10, 11. Query video and ge result from DB<br />12,13.  Set Video with status = available and data in both cache and mem.<br />
  18. 18. Dot Server<br />Why<br />Adserver高可用性保护方案以应对突发峰值和Bug down机.<br />触发Down机的bug往往会中断全部应用服务器<br />What<br />服务器内维持一个待服务请求队列, 当排队请求超过阈值<br />或由某用户请求触发特定Bug,导致机群相继Down机<br />后续请求转到一个无逻辑的Server Farm,并返回一个cache的无广告标准输出.<br />最大可能避免对外服务失效<br />
  19. 19. 无状态日志处理<br />日志处理设计的主要考虑因素:<br />减少日志体积,容易扩展,避免自己定义格式和写Parser<br />Text Log -> Binary log by Google Protocol buffer<br />用较少的机器达到较高吞吐量:理想情况下接近磁盘I/O<br />日志收集分区,一个Node只处理固定一组广告服务器日志<br />尽量减少日志中需要交换处理的内容<br />MapReduce由Hadoop/Java 转C++<br />Aggregation由Python转C++<br />重处理:中断后,容易从头开始,避免人工接续处理<br />无状态设计的关键:<br />日志条目自身应包含交易所有现场和Callback的必要信息<br />不变的Meta Data通过Pusher从OLTP中提取<br />
  20. 20. 日志格式变化<br />Protocol Buffer Binarylog:<br />advertisement {<br />ad_id: 29:121 <br />ad_replica_id: 0 <br />rendition_id: 40:20 <br /> flags: 0:9 <br />slot_index: 0 <br /> associate: VIDEO <br />content_right_owner { <br />network_id: 6:10 <br /> revenue: 0.0 <br />inventory_id: 1:10 <br />context_id: 4:10 <br /> } <br /> distributor { <br />network_id: 6:10 <br />up_network_id: -1 <br /> revenue: 0.0 <br />up_revenue: 0.0 <br />inventory_id: 1:10<br /> }<br /> …<br />Text Log:<br />ad_id, ad_replica_id, rendition_id, flags, slot_index, associate, cro_ network_id, cro_revenue, cro_inventory_id,cro_context_id,dist_network_id,dist_up_network_id,dist_revenue,dist_up_revenue,dist_inventory_id<br /> 29:121,0,40:20,0:9,VIDEO,6:10,0.0,1:10,4:10,6:10,-1,0.0,0.0,1:10<br />Protocol Buffer Binlogvs Text Log<br /><ul><li>扩展字段方便
  21. 21. 现成Parser
  22. 22. 存储更小</li></li></ul><li>数据仓库扩展<br />易于查询和建模:Normalization vs De-normalization<br />优化行数:<br />Pivot<br />Long tail roll up & Data Availability<br />基于Benchmarking优化查询<br />Table Partition<br />DB Sharding<br />分离data loading与Query的冲突: Split Loading<br />
  23. 23. Normalization<br />优点:<br />Fact 表精简,数据无冗余<br />缺点:<br />当业务逻辑复杂时,查询可能变得很复杂,需多次Join。<br />当需要按照某个dimension ID做Group by时不能有效利用fact表索引,尤其当Fact表数据量较大时,性能难以接受。<br />
  24. 24. De-Normalization<br />优点:<br />Star Schema,将复杂逻辑放到外部程序,而使得SQL逻辑简单,fact表不增加行,查询性能较好。<br />标准BI工具建模容易。<br />缺点:<br />Fact表增加了冗余列和存储(查询性能主要与行数相关)<br />
  25. 25. Pivot<br />优点:<br />通过转秩(Pivot),使原来分布在fact表中相同Key组合的多行数据合并到一行,减少了行数,使SQL更加简单,提高查询性能。在大数据量时收益明显。<br />缺点:<br />fact表单条记录增加了列;需开发程序完成转秩。<br />
  26. 26. Long tail roll up & Data Availability<br />一个简单的计算: 100,000 video X 100 site X 100 Country X 1,000 Ad = 1,000,000,000,000 行/天,Impossible!<br />互联网视频的访问热度呈现典型“长尾”分布<br />5%的热门视频占有50%的流量<br />在所有视频上统计所有维度/粒度的指标,ROI太低<br />Long Tail Roll up<br />对单日小于某一阈值流量的video在DB中roll up成一个item<br />创建Long tail表单独对长尾视频做粗粒度统计<br />Data Availability<br />对不需要某些粒度指标的客户不统计相关维度<br />产品功能设计需谨慎,一旦发布很难收回,从而带来维护负担<br />
  27. 27. Benchmarking与查询优化<br />自动Benchmark所有查询<br />使用Production数据<br />自动check out SQL运行<br />提取MySQL Slow Query log测量值,多次测量平均<br />月度评审,选择top slow query优化<br />查询优化<br />Schema设计应尽量让SQL简单,复杂逻辑放到应用程序<br />正确建立和使用必要的索引<br />InnoDB buffer设置,70%机器内存<br />参考:《高性能MySQL》(第二版)<br />http://www.mysqlperformanceblog.com/<br />
  28. 28. Benchmarking (Case Demo)<br />Internal Benchmark Tool<br />Benchmark Report w queries run longer than 10 min<br />
  29. 29. Partition and Sharding<br />做完上述优化以后的选择<br />Table Partition: <br />选择event_date作为Key<br />以Partition为单位增、删数据仓库表,几乎不用Update<br />Sharding的收益:<br />容易为新客户扩展<br />限制错误影响范围<br />客户数据相对隔离,更容易添加新DB<br />避免单点故障<br />可并行Load数据,提高发布效率<br />Sharding的代价:<br />增加硬件、架构和监控的复杂性<br />
  30. 30. DB Volume Increase Trendline Before Sharding<br />29<br />
  31. 31. Problem<br />Database<br />1.1T<br />1.1T<br />Swap<br />Read<br />Write<br /><ul><li>Bad query performance!
  32. 32. Impossible to do migration and reprocess!
  33. 33. Hard to scale!</li></ul>30<br />
  34. 34. Sharding Architecture <br />31<br />Client Facing End <br />Shard 2<br />Shard 3<br />Shard 1<br /> Huge DB<br />
  35. 35. 基于Sharding下的ETL流程演示<br />32<br />Client Facing End <br /> 服务中<br />X<br />X<br />X<br />X<br />X<br />X<br /> 脱离服务<br />加载数据..<br />ETL<br />
  36. 36. 运营原则——50% 上限 & N+1 Data Center<br />所有子系统做容量扩展规划时,预估上限以50%负载(经验值)为限。<br />Adserver为峰值预留50%容量,e.g突发新闻,世界杯决赛<br />后台日志处理在用户要求的数据发布时间50%内完成,有机会应对意外出错重做一遍。<br />业务量上涨导致系统平均负载>50%,扩容的信号!<br />N+1 Data Center<br />数据中心不同地理位置分布<br />备用ISP,备用CDN<br />保证一个DC由于意外服务中断,其他N个可正常负载服务。<br />
  37. 37. 监控与响应<br />监控分类:<br />应用服务Check Live<br />服务异常警报:错误,延时等<br />数据库Master-Slave同步<br />Cache有效性:Quick Push<br />端到端数据一致性检验:模拟用户行为<br />Slow Query日报<br />当日业务运营情况日报<br />响应:<br />优先级: P1/P2/P3<br />7x24 On-Call Rotation<br />
  38. 38. 示例:应用服务Check Live日报<br />示例:数据一致性监控报警<br />
  39. 39. 多阶段部署<br />正式上线前Staging部署<br />一个按比例构建的模拟生产环境,包括所有类型应用服务<br />拓扑结构与生产环境相同<br />使用生产环境的数据库数据和真实用户请求采用模拟<br />可充当集成测试环境<br />生产环境分阶段部署<br />降低因升级造成服务中断的风险<br />将集群分组,分批分时升级<br />兼容性挑战<br />Rollback计划<br />
  40. 40. 关于测试的一点话题<br />以自动化回归测试为核心<br />并未使用TDD单元测试<br />坚持Local测试->集成测试->回归测试->Staging<br />每次升级发布前的测试检查清单<br />New Feature Function Test<br />UI/Core/VI Integration Test<br />Regression Case Suite<br />Memory Leak Check<br />Performance Test<br />Compatible Test<br />Post Release Live Check<br />
  41. 41. 关于测试(回归测试系统 Demo)<br />
  42. 42. 系统演化路线图<br />第一阶段:2007年12月 – 2008年6月 <br />目标:上线,验证服务可用性<br />扩展工作:Push/Quick Push,监控,日志处理架构<br />集群规模:20台广告服务器,4ETL, 4 预测,3 OLTP, 1 OLAP.<br />业务量:日均几万至几十万次访问,日志量<1G/天<br />第二阶段:2008年6月--2009年9月<br />目标:扩展服务客户,数据仓库调优<br />扩展方面的主要工作:memcache,Binarylog,数据仓库Denormalize/Pivot/Partition/Benchmarking<br />集群规模:+20 广告服务器,+2 MemcacheD,+2ETL, +2预测,+1 OLAP。<br />业务量:日均几百万次访问,日志量约10G/天<br />
  43. 43. 当前运营情况<br />第三阶段:2009年10月--至今<br />目标:支持大客户,运营友好<br />扩展工作:DB Sharding,Dot Server, 多阶段部署<br />集群规模:<br />广告服务器:60台,日均服务视频广告请求5000万次,广告投放量约1亿次,5%负载。<br />后台日志处理:8台,日均4小时处理日志200G,20%负载<br />预测系统:6台,日均4小时模拟500万请求,20%负载<br />数据仓库:日新增约1000万条记录~10G存储,1T/Shard<br />
  44. 44. 2009.5-2010.3间流量增长20倍!<br />服务流量趋势和可用性<br />Service Level Agreement (SLA) >= 99.99%<br />
  45. 45. 关于分布式系统和Web服务扩展相关链接<br />Blogs<br />NatiShalom's Blog: Discussions about middleware and distributed technologieshttp://natishalom.typepad.com/nati_shaloms_blog/<br />All Things Distributed: Werner Vogels' weblog on building scalable and robust distributed systems.http://www.allthingsdistributed.com/<br />High Scalability: Building bigger, faster, more reliable websiteshttp://highscalability.com/<br />ProductionScale: Information Technology, Scalability, Technology Operations, and Cloud Computinghttp://www.productionscale.com/<br />iamcal.comhttp://www.iamcal.com/ (the "talks" section is particularly interesting)<br />Kitchen Soap: Thoughts on capacity planning and web operationshttp://www.kitchensoap.com/<br />MySQL Performance Blog: Everything about MySQL Performancehttp://www.mysqlperformanceblog.com/<br />
  46. 46. Presentations<br />Scalable Internet Architectureshttp://www.slideshare.net/shiflett/scalable-internet-architectures<br />How to build the Webhttp://www.slideshare.net/simon/how-to-build-the-web<br />Netlog: What we learned about scalability & high availabilityhttp://www.slideshare.net/folke/netlog-what-we-learned-about-scalability-high-availability-430211<br />Database Sharding at Netloghttp://www.slideshare.net/oemebamo/database-sharding-at-netlog-presentation<br />MySQL 2007 Techn At Digg V3http://www.slideshare.net/epee/mysql-2007-tech-at-digg-v3<br />Flickr and PHPhttp://www.slideshare.net/coolpics/flickr-44054<br />Scalable Web Architectures: Common Patterns and Approacheshttp://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches<br />How to scale your web apphttp://www.slideshare.net/Georgio_1999/how-to-scale-your-web-app<br />Google Cluster Innardshttp://www.slideshare.net/ultradvorka/google-cluster-innards<br />Sharding Architectureshttp://www.slideshare.net/guest0e6d5e/sharding-architectures<br />
  47. 47. 关于FreeWhel<br />FreeWheel是目前全美领先的互联网数字视频广告管理和增值服务提供商,创始人团队由前DoubleClick高管组成,在美国网络广告界拥有多年市场、产品、技术和管理方面的资深经验。<br />公司创立于2007年,由Battery Ventures和Foundation Venture投资,并于2010年3月完成第三轮1680万美元注资,引入迪斯尼Steamboat Venture和特纳广播公司(Turner)作为战略投资人。<br />公司专注于为大型媒体公司和互联网视频网站提供视频广告管理系统与增值服务,现有客户包括ESPN,华纳, CBS, Discovery, CNBC, CNN.com, NBA.com, ESPN.com, MLB.com, Veoh.com, Vevo.com等,月度广告业务服务量约20亿次,并仍在快速增长。<br />FreeWheel目前在硅谷、纽约和北京设有机构,其中北京研发中心担负全部的产品研发工作,包括核心广告系统、Web应用以及视频设备整合等。<br /> <br />
  48. 48. FreeWheel北京工程师团队<br />
  49. 49. 谢谢大家!<br />Q&A<br />

×