youtub使用Python技术的成功案例之二

.YouTubeStingChen〔陈世欣〕使用Python技术的成功案例之二名媛荟网MY1930.COMCTOTwitter：@stingchen博客：BOPOR.COM假设每个公司用一个协议栈表示，可能如下使命和目标〔梦想、目标、宗旨〕文化和结构〔文化、制度、团队组织〕业务和市场〔模式、推广、销售〕产品〔筹划、功能、细分市场〕设计〔界面设计、交互设计，用户体验〕前端〔页面模板、JS、AS〕程序〔架构、设计、写代码、测试〕运维〔平安、日志、性能、备份〕故事起源2005年1月陈士骏及YouTube另一位创始人查德.赫利都离开了前一个工作。在一次烤肉的聚会中，陈士骏苦于找不到地方与人分享录像带，心想如果能放在网络上，必定吸引很多同好。于是两人就在查德.赫利家中的车库设计网络视频分享的方案，YouTube因此诞生。2006年10月，谷歌(Google)以16.5亿美元收购美国加州初创视频网站YouTube，使包括华裔陈士骏在内的YouTube两名创始人一夜间成为巨富。以16亿5000万美元除以YouTube五千多万用户，平均一个用户作价32美元于2006年3月到达每天3千万的视频点击量

于2006年7月到达每天1亿的视频点击量2021年5月占据43.1%市场份额的YouTube里他们有超过140亿段视频被用户观看，刷新了自己的记录，这相当于每名YouTube访客在5月里观看了超过100段视频〔仅限美国地区〕创始人陈士骏(SteveChen)–CTO,美籍台湾人，1978年生于中国台湾，8岁随父母移居美国1995年进入伊利诺伊大学计算机系学习1999年，在大学四年级时中途辍学，到只有4人的贝宝(PayPal)工作。谷歌公司2006年收购YouTube视频网站时，获得的总价值为3.01亿美元查德.赫利(ChadHarley)–CEO毕业于印第安那大学设计专业，毕业后在网络支付网站PayPal工作了几年，是PayPal的第15位员工，也是第一位美工。PayPal被eBay收购后，赫利转而为多家IT公司提供咨询效劳，与此同时，他还在好莱坞充当制片人，推出的作品包括喜剧?多谢抽烟?。贾韦德·卡里姆斯坦福大学未毕业学生，早先参加paypal持有的YouTube股份当时价值6600万美元创意灵感源自印尼海啸31岁的瑞典修车工人汤米在印尼的普吉岛度假，突然，“轰隆轰隆〞，海上响起奇怪的低吟声，霎时，3层楼高的海浪凌空席卷！汤米大叫快跑，随手拿起，拍下这一幕南亚海啸短片刚播放，就有12个博客转载，其中一个原本无名的博客，人气从零5天内吸引了68万人次上线观看，当时至少有超过130万人在网络上看到南亚海啸的内容，这个数字，比美国?商业周刊?每周120万本的发行量还高。这那么短片最早在挪威的?Dagbladet?日报网站上播放，12小时内，包含CNN在内的全球媒体都在追着汤米买影带。陈士骏3人惊觉，科技的进步已让全民都拥有了创作权，修车工人也能打败CNN记者。创始理念相信消费者至上，相信‘你(You)’是最重要的。希望创立一个视频内容共享社区,让公众上传任何格式的视频内容，同时为此提供一个视频播放器，用户可将视频内容放置于网站或博客当中，并与他人分享。想法很实际，不是自顾自地在车库里研发产品，还要想到市场。效率很重要，时间要有效率，用钱也是如此，像我不会聘用没有效率的员工。开发的产品一套简单的程序，可以支持各种各样的视频文件，任何电脑用任何网络浏览器都可以播放这些视频文件。然后创立了一个网上视频社群，人们可以存这个网站上发布自己制作的视频，观看、搜索其他人的作品，并进行评论和评级。

低本钱的起步几台计算机，一张信用卡(陈士骏的信用卡)，就把系统建立起来了。又过了三个月，伙伴们愁眉苦脸地坐在堆满杂物的车库里对望，他们想提供平台给eBay网络拍卖者使用，但卖方不喜欢以影片介绍产品，结果就是“没有人用〞。松开双手，“创造〔消费者〕要的产品。〞他们宣布，提供“嵌入式效劳〞，消费者上传影片到YouTube网站后，其他喜欢影片或是想要欣赏影片的人，可以直接设立链接，贴到自己的网页上。也就是说，所有人不须要进入YouTube的网站，在自己的网页上就能看到那些影片。YouTube成功的秘诀是什么?首先是简单简单其实才是互联网上最重要的法那么。从一开始就是为了用户使用方便而设计，把那些看似笨重，困难的过程变得简单。YouTube是第一家使用FlashVideo的，这样再不用关心你最初安装的是什么样的媒体播放器，把所有的视频都转化为了一种普通格式。YouTube的页面干凈，导航也很容易。YouTube成功的秘诀是什么?其次是对于细节的关注用户收到一个链接，点击，翻开浏览器，这里面的视频应该是自动播放，而不是需要用户再点一下分享的链接。在YouTube的每一个视频旁边，都有一个让用户可以粘贴到MSN或者网页里面的代码。其实，这个URL在浏览器上面的地址栏里也有，用户可以把鼠标挪上去，然后拷贝下来。但是把这个链接放在视频的右侧，就那么近，那么容易看到，容易明白，容易拷贝YouTube里视频的URL都很短，比方://=Lcfx7v-z-JE，这样做的优势在于，能够确保在即时通讯工具或者邮件里面不会折行，从而影响翻开。每天超过1亿的视频点击量时候的技术团队配置 2个系统管理员2个伸缩性软件架构师2个软件开发工程师2个网络工程师1个DBA

平台Apache

Python

Linux(SuSe)

MySQL

psyco，一个动态的Python到C的编译器

ligd代替Apache做视频查看

Web效劳器端的一些运营情况NetScaler用于负载均衡和静态内容缓存使用mod_fast_cgi运行Apache使用一个Python应用效劳器来处理请求的路由应用效劳器与多个数据库和其他信息源交互来获取数据和格式化html页面一般可以通过添加更多的机器来在Web层提高伸缩性Web效劳器端的一些运营情况Python的Web层代码通常不是性能瓶颈，大局部时间阻塞在RPCPython允许快速而灵活的开发和部署通常每个页面效劳少于100毫秒的时间使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环对于像加密等密集型CPU活动，使用C扩展Web效劳器端的一些运营情况对于一些开销昂贵的块使用预先生成并缓存的html数据库里使用行级缓存缓存完整的Python对象有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用效劳器里最快的缓存将预先计算的值发送给所有效劳器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。视频效劳相关的一些情况花费包括带宽，硬件和能源消耗每个视频由一个迷你集群来host，每个视频被超过一台机器持有，这样做的好处有：更多的硬盘来持有内容意味着更快的速度failover。如果一台机器出故障了，另外的机器可以继续效劳在线备份视频效劳用ligd作为Web效劳器来提供视频效劳：Apache开销太大使用epoll来等待多个fds从单进程配置转变为多进程配置来处理更多的连接大局部流行的内容移到CDN：CDN在多个地方备份内容，这样内容离用户更近的时机就会更高CDN机器经常内存缺乏，因为内容太流行以致很少有内容进出内存的颠簸视频效劳不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube效劳器长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。调节RAID控制并注意其他低级问题调节每台机器上的内存，不要太多也不要太少视频效劳关键点保持简单和廉价保持简单网络路径，在内容和用户间不要有太多设备使用常用硬件，昂贵的硬件很难找到帮助文档使用简单而常见的工具，使用构建在Linux里或之上的大局部工具很好的处理随机查找(SATA，tweaks)

缩略图效劳做到高效及其困难每个视频大概4张缩略图，所以缩略图比视频多很多缩略图仅仅host在几个机器上缩略图效劳持有一些小东西所遇到的问题：OS级别的大量的硬盘查找和inode和页面缓存问题单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意每秒大量的请求，因为Web页面可能在页面上显示60个缩略图在这种高负载下Apache表现的非常糟糕在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个尝试使用ligd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存如此多的图片以致一台新机器只能接管24小时重启机器需要6-10小时来缓存缩略图效劳为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：防止小文件问题，因为它将文件收集到一起快，错误容忍更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作Python的优化措施-问题纯python的加密模块HMAC

(Hash-basedMessageAuthenticationCode)要占用40%的cpu应对策略：用C语言重写，提高性能大量评论的显示问题：过于复杂的算法去计算显示对象树应对策略：简化查询,简化算法Python的优化措施使用psyco–加快Python执行的编译器最常用的功能都是用psyco编译由于存在上下文切换开销，需要测试优化后大量评论的显示性能closure+psyco=提高性能达400%closure

：AJavaScriptoptimizer怎样获得可以接受的性能？效劳的扩展对各种“叶子级别〞的效劳进行优化动态web请求是一种`效劳`webservice容易扩展,可以向外扩展数据库的扩展数据库很难扩展，需要聪明的逐步升级的技巧但，慢慢地就没有牌可以打了MySQL性能扩展不得不做大量水平切分需要仔细选择分库方案理解数据访问模式最常用的查询是什么？使用到了Join没有需要事务一致性吗？为什么？是否可以进行“实体〞的融合?MySQL性能扩展必须根据实体进行分块实体是事务一致性的实体内部属性允许交互连接实体容易迁移交叉实体过于复杂减弱实体中的一些保证要求、简化实体通过设计减少相关活动MySQL性能扩展数据库优化实践相关操作连接和事务管理查询效劳机制〔lookupservice〕建立查询工厂，并发查询〔queryfactory〕抽取最小表的集合，加快查询，禁止ORM简化最常用的用户行为设计程序设计对实际数据库透明整个网站运营中循环进行的主题简单的优雅选择可靠的开源软件，然后做定制化`pythonicveneer`DIY–

发现一个问题并不够，鼓励发现者自己动手去解决这个问题。总结的经验用短期方案赢得问题解决时间在考虑长远解决方案时候，一些技巧性但有些风险的短期方案可以帮你渡过难关任何事情都按照优先级安排清晰了解什么对你的效劳和资源最重要的，资源和工作总是按照优先级来安排外包一些重要的效劳自己做一些效劳化时间长，本钱也高。比方CDN保持简单这样可以重构更快，响应问题更快。也许没有人知道什么是简单的设计。如果你不害怕做改变，那就是一个信号。总结的经验切片(Shard)切片的设计思路不仅仅获得更好的写性能，还能帮助隔离和限制所有资源包括存储、CPU