详解YouTube的架构原则和扩展经验

YouTube发展迅速，每天视频点击量超过1亿，但维护站点并保证伸缩性的人却寥寥无几。这类似于PlentyOffish，少数人维护庞大的系统。原因是什么？放心，绝对不是靠性格，也不是靠孤独。我们来看看YouTube的整体技术结构。平台    ApachePythonLinux(SuSe)MySQLpsyco，动态Python到C的编译lightpd取代Apache进行视频查看状态，支持2005年2月和2006年3月每天3000万视频点击，2006年7月每天1亿视频点击，2个可伸缩软件架构师2个软件开发工程师，2个网络工程师，1DBAWeb服务器1，NetScaler用于负载均衡和静态内容缓存2fast_cgi运行Apache3，使用Python应用程序服务器来处理要求的路由4，应用程序服务器与多个数据库和其他信息源交互，以获取数据和格式化html页面5，通常可以添加更多的机器来提高web层的可伸缩性6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC7，Python允许快速灵活地开发和部署8，通常每个页面服务不到100毫秒的时间9，使用Psyco(类似JIT编译器的动态Python到C的编译器)来优化内部循环10。对于一些昂贵的块使用预先生成和缓存的html12，数据库使用行级缓存13，缓存完整的python对象14，一些数据被计算并发送到每个程序，因此这些值缓存在本地内存中。这是一种使用不当的策略。这是一种使用不当的策略。应用服务器中最快的缓存不需要太多时间就能将预计值发送给所有服务器。只需得到一个代理来监控变更，预计算，然后发送。视频服务1，成本包括带宽、硬件和能源消耗2，每个视频由一个迷你集群组成，每个视频由一台以上的机器持有3，使用一个集群意味着：  -更多的硬盘持有内容意味着更快  -failover。如果一台机器出了问题，另一台机器可以继续服务  -在线备份4，使用lighttpd作为Web服务器提供视频服务：  -Apache的费用太大了  -使用epoll等待多个fds  -从单过程配置到多过程配置，处理更多的连接5，大部分流行内容转移到CDN： -CDN在多个地方备份内容，这样，内容更接近用户的机会就会更高 -CDN机器往往内存不足，因为内容太流行，内容进出内存的颠簸很少。6.不太流行的内容(每天浏览1-20次)在很多colo站点使用YouTube服务器。 -长尾效应。一个视频可以播放多个视频，但是很多视频都在播放。多个视频可以播放，但许多视频正在播放。随机硬盘块被访问 -在这种情况下，缓存不是很好，所以花钱在更多的缓存上可能没有多大意义。 -调整RAID控制，注意其他低级问题 -调整每台机器上的内存，不要太多或太少 视频服务关键点    1.保持简单和便宜。2.保持简单的网络路径。内容和用户之间不应该有太多的设备。3.使用常用硬件，很难找到昂贵的硬件来帮助文档。4.使用简单而常见的工具，使用大多数建在Linux或以上的工具5，可以很好地处理随机搜索(SATA，tweaks)缩略图服务1，达到高效惊人的难度2，每个视频大概有4个缩略图，所以缩略图比视频多很多3，缩略图只有几台机器上的host4，持有一些小东西遇到的问题：  -OS级别的大量硬盘搜索、inode和页面缓存问题  -单目录文件限制，特别是Ext3，后来移动到多层结构。最近内核2.6的改进可能使Ext3允许大目录，但在文件系统中存储大量文件并不是一个好主意  -每秒都有大量的请求，因为web页面可能会在页面上显示60个缩略图  -Apache在这种高负载下的表现非常糟糕  -在Apache前端使用squid，这样工作了一段时间，但由于负载继续增加，以失败告终。它把每秒300个请求变成了20个请求  -尽量使用lighttpd，但由于使用单线程，它陷入了困境。遇到多过程问题，因为它们保持自己独立的缓存  -这么多图片，一台新机器只能接管24小时  -重启机器需要6-10个小时来缓存5，YouTube开始使用GogleBigTable来解决所有这些问题，分布式数据存储：  -避免小文件问题，因为它收集文件在一起  -快，容忍错误  -由于使用分布式多级缓存，延迟较低，该缓存与多个不同的collocation站点一起工作  -更多信息参考GoogleArchitecture，GoogletalkArchitecture和Bigtable数据库    1，早期  -使用MySQL存储元数据，如用户、tags和描述  -用RAID10存储整个10硬盘的数据  -YouTube依靠信用卡租用硬件  -YouTube经历了一场常见的革命：单服务器，然后是单master和多readslaves，然后是数据库分区，然后sharding模式  -痛苦和备份延迟。master数据库是多线程的，运行在大机器上，所以可以处理很多工作。slaves是单线程的，通常运行在较小的服务器上，备份是异步的，所以slaves会远远落后于master。  -更新导致缓存失效，慢I/O硬盘导致慢备份  -使用备份架构需要大量的money来获得更高的写作性能  -YouTube的解决方案之一是将数据分为两个集群，将传输分为优先级：视频查看池和一般集群2，后期  -数据库分区  -分为shards，不同的用户指定不同的shards  -扩散读写  -更好的缓存位置意味着更少的IO  -硬件减少30%  -备份延迟减少到0  -依靠信用卡，可以随意完善数据库的可伸缩性数据中心策略1，因此，一开始只能使用受管主机提供商2，受管主机提供商无法提供可伸缩性，无法控制硬件或使用良好的网络协议3，YouTube改为使用colocationarangement。现在YouTube可以定制一切，并同意自己的合同4，使用5到6个数据中心和CDN5，视频来自任何数据中心，而不是最近的匹配或其他任何东西。现在YouTube可以定制一切并同意自己的合同4，使用5到6个数据中心和CDN5，视频来自任何数据中心，而不是最近的匹配或其他任何东西。如果一个视频足够受欢迎，它将移动到CDN6，这取决于视频带宽，而不是真正的延迟。可以来自任何colo7，图片延迟非常严重，特别是当一个页面有60张图片时，使用bigtable将图片备份到不同的数据中心，代码查看谁是最近的扩展思维，虽然下面不是一个新想法，但我希望它能帮助你。分而治之是扩展技术的灵魂。考虑以层次化的方式完成所有工作。这也是数据分片的症结。要知道如何将数据分区，以及如何将分区的数据连接起来。总而言之，保持简单和松散的耦合是非常必要的。充分利用Python的动态特性，构建易于扩展的软件架构。近似的正确性。相信监控系统报告的系统运行状态。假如问题没有出现，就认为一切都很好。不一致的数据模型。比如读评论的人和写评论的人会对你刷新页面的动作有不同的反应，但是不需要完全基于事务处理进行系统设计，会显得过度矫枉过正。我们仍然需要不一致的数据模型。分布式系统的随机性。像气象系统一样，分布式系统在调试分布式系统时会有更多的随机性。例如，缓存过期。一般情况下，服务器会缓存流行视频24小时。如果缓存同时过期，服务器将同时开始缓存，负载如雷声！最快的函数调用是不做任何调用。合理设计事务处理的间隔和次数。仔细观察API，心中有数。如何定义输入和输出？本质上，所有的函数调用都是围绕数据发生的。函数调用后会发生什么？RPC重定向应用于Python。程序员是代码的构建者，所以要做好协议。如果代码不幸失败，也可以从RPC输出中追踪原因。没有完美的组件。一个组件的运行周期可能会持续1-6个月，没有人知道它会持续多久。随着时间的推移，我们会用Python和C重写一些东西，这证明你正在淘汰旧组件，当你观察到一个新组件出现时，它就诞生了。没有人知道整个系统的运行机制。因此，我们需要定义组件。视频转码与视频搜索完全不同，建立良好的数据规范非常重要。效率与可扩展性并重。最有效的是用C实现过程，但这种方法缺乏可扩展性。*宏观层面、组件及其失败的原因。使用RPC明智吗？内联如何？分解研究可能会发现不同之处。重视算法。与其绞尽脑汁用Python来实现高效算法，不如用它来做更实用的事情。C语言在这方面有其优势。很少从事面向对象的设计。我们使用大量的名称空间来组织数据，但很少面向对象。我愿意用以下词来形容我们的代码树:简单、实用、优雅、正交、可组合，这是我们的追求。总结YouTube解决问题的哲学只有一个词:简单。许多YouTube产品最初来自一个简单的Python脚本。这是我们的一句老话，不积小步，不至千里；不积小流，不能成江海。