YouTube 架构 · HighScalability 中文示例

# YouTube 架构 > 原文： [http://highscalability.com/blog/2008/3/12/youtube-architecture.html](http://highscalability.com/blog/2008/3/12/youtube-architecture.html) **更新 3：** [在 30 分钟内进行 7 年的 YouTube 可扩展性课程](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html)和 [YouTube 策略：添加抖动不是一个错误](http://highscalability.com/blog/2012/4/17/youtube-strategy-adding-jitter-isnt-a-bug.html) [](http://highscalability.com/blog/2012/4/17/youtube-strategy-adding-jitter-isnt-a-bug.html)**更新 2：** [YouTube 每天达到 10 亿观看](http://mashable.com/2009/10/09/youtube-billion-views/)。 *即每秒至少 11574 次观看，每分钟 694444 次观看和每小时 41666666667 次观看。* **更新：** [YouTube：平台](http://www.techcrunch.com/2008/03/12/youtube-the-platform/)。 YouTube 添加了一组丰富的新 API，以免费成为您的视频平台领导者。在您自己的网站上上传，编辑，观看，搜索和评论视频，而无需访问 YouTube。通过 API 在内部组成您的网站，因为无论如何以后您都需要公开它们。 YouTube 的增长速度非常快，每天的视频观看次数超过 1 亿，只有少数人负责网站的扩展。他们如何设法将所有视频交付给所有这些用户？自从 Google 收购以来，它们又如何发展？ ## 信息来源 1. [Google 视频](https://www.youtube.com/watch?v=w5WVu624fY8) ## 平台 1. 阿帕奇 2. 蟒蛇 3. Linux（SuSe） 4. 的 MySQL 5. psyco，动态 python- > C 编译器 6. 用于视频而不是 Apache 的 lighttpd ## 里面有什么？ ### 统计资料 1. 支持每天交付超过 1 亿个视频。 2. 成立于 2/2005 3. 3/2006 每天 3000 万次视频观看 4. 7/2006 每天有 1 亿次视频观看 5. 2 位系统管理员，2 位可扩展软件架构师 6. 2 位功能开发人员，2 位网络工程师，1 位 DBA ### 处理快速增长的配方 `while (true) { identify_and_fix_bottlenecks(); drink(); sleep(); notice_new_bottleneck(); }` 该循环每天运行多次。 ### 网络服务器 1. NetScalar 用于负载平衡和缓存静态内容。 2. 使用 mod_fast_cgi 运行 Apache。 3. 请求被路由以由 Python 应用服务器处理。 4. 应用服务器与各种数据库和其他信息源进行对话，以获取所有数据并格式化 html 页面。 5. 通常可以通过添加更多计算机来扩展 Web 层。 6. Python Web 代码通常不是瓶颈，它大部分时间都花在了 RPC 上。 7. Python 允许快速灵活的开发和部署。考虑到他们面临的竞争，这至关重要。 8. 通常少于 100 毫秒的页面服务时间。 9. 使用 psyco，这是一种动态 python- > C 编译器，它使用 JIT 编译器方法来优化内部循环。 10. 对于诸如加密之类的占用大量 CPU 资源的活动，它们使用 C 扩展名。 11. 一些预生成的缓存 HTML，用于渲染块很昂贵。 12. 数据库中的行级缓存。 13. 完整格式的 Python 对象将被缓存。 14. 计算一些数据并将其发送到每个应用程序，以便将这些值缓存在本地内存中。这是一个未被充分利用的策略。最快的缓存位于您的应用程序服务器中，不需要花费很多时间就可以将预先计算的数据发送到所有服务器。只需要一个代理来监视更改，预先计算和发送即可。 ### 影片投放 * 成本包括带宽，硬件和功耗。* 每个视频由一个迷你集群托管。每个视频由一台以上的机器提供。* 使用群集意味着： -提供内容的更多磁盘意味着更高的速度。 -净空。如果机器故障，其他人可以接管。 -有在线备份。* 服务器将 lighttpd Web 服务器用于视频： -Apache 的开销太大。 -使用 epoll 等待多个 fds。 -从单进程配置切换到多进程配置以处理更多连接。* 最受欢迎的内容已移至 CDN（内容交付网络）： -CDN 在多个位置复制内容。更有可能使内容更接近用户，跳数更少，并且内容将在更友好的网络上运行。 -CDN 机器主要用于内存不足，因为内容是如此受欢迎，几乎没有内容在内存中跳动的情况。* 不太受欢迎的内容（每天 1-20 次观看）在各种 colo 网站中使用 YouTube 服务器。 -有长尾巴效果。视频可能有一些播放，但是正在播放很多视频。正在访问随机磁盘块。 -在这种情况下，缓存没有太大的用处，因此花钱购买更多的缓存可能没有意义。这是非常有趣的一点。如果您的产品尾部很长，那么缓存并不总是您的性能救星。 -调整 RAID 控制器，并注意其他较低级别的问题以提供帮助。 -调整每台机器上的内存，所以不要太多也不要太少。 ### 提供视频关键点 1. 保持简单和便宜。 2. 保持简单的网络路径。内容和用户之间没有太多设备。路由器，交换机和其他设备可能无法承受如此多的负载。 3. 使用商品硬件。硬件越昂贵，其他所有东西（支持合同）也就越昂贵。您也不太可能在网上找到帮助。 4. 使用简单的通用工具。他们使用大多数内置在 Linux 中的工具，并在这些工具之上。 5. 处理随机寻优（SATA，调整）。 ### 服务缩图 * 出人意料的是，很难高效地进行。* 每个视频都有大约 4 个缩略图，因此缩略图比视频要多得多。* 缩略图仅托管在几台计算机上。* 看到了与服务许多小对象相关的问题： -大量磁盘搜索以及操作系统级别的 inode 高速缓存和页面高速缓存出现问题。 -进入每个目录文件的限制。特别是 Ext3。转移到更分层的结构。 2.6 内核的最新改进可以将 Ext3 大目录处理提高到[的 100 倍](http://ext2.sourceforge.net/2005-ols/paper-html/node3.html)，但是在文件系统中存储大量文件仍然不是一个好主意。 -大量请求/秒，因为网页可以在页面上显示 60 个缩略图。 -在如此高的负载下，Apache 的表现很差。 -在 Apache 前面使用过的鱿鱼（反向代理）。这工作了一段时间，但是随着负载的增加，性能最终下降了。从 300 请求/秒增加到 20。 -使用 lighttpd 尝试过，但是只有一个线程使它停顿了。在多进程模式下会遇到问题，因为它们每个都会保留一个单独的缓存。 -设置了如此多的图像后，一台新机器花费了 24 小时。 -重新启动计算机需要 6 到 10 个小时才能将缓存预热，以使其不进入磁盘。* 为了解决他们所有的问题，他们开始使用 Google 的 BigTable（分布式数据存储）： -避免小文件问题，因为它将文件聚集在一起。 -快速，容错。假定它在不可靠的网络上工作。 -较低的延迟，因为它使用了分布式多级缓存。此缓存可在不同的并置站点上工作。 -有关 BigTable 的更多信息，请查看 [Google 架构](http://highscalability.com/google-architecture)， [GoogleTalk 架构](http://highscalability.com/googletalk-architecture)和 [BigTable](http://highscalability.com/tags/bigtable) 。 ### 资料库 1. 早期 -使用 MySQL 存储元数据，例如用户，标签和说明。 -从具有 10 个磁盘的单片 RAID 10 卷中提供数据。 -以信用卡为生，因此可以租用硬件。当他们需要更多硬件来处理负载时，花了几天时间订购并交付。 -他们经历了一个共同的演变：单个服务器，转到具有多个读取从属的单个主机，然后对数据库进行分区，然后决定采用分片方法。 -出现复制延迟。主机是多线程的，可在大型计算机上运行，因此它可以处理大量工作。从站是单线程的，通常在较小的计算机上运行，并且复制是异步的，因此从站可能会大大落后于主站。 -更新导致高速缓存未命中，而高速缓存 I / O 导致复制缓慢的磁盘丢失。 -使用复制体系结构，您需要花费大量金钱来增加写入性能。 -他们的解决方案之一是通过将数据分为两个集群来优先处理流量：视频观看池和通用集群。这个想法是人们希望观看视频，以便该功能应获得最多的资源。 YouTube 的社交功能不太重要，因此可以将其路由到功能较弱的群集中。 2. 后来的几年： -进行数据库分区。 -分为多个分片，用户分配了不同的分片。 -传播写入和读取。 -更好的缓存位置，意味着更少的 IO。 -导致硬件减少 30％。 -复制副本延迟减少到 0。 -现在几乎可以任意扩展数据库了。 ### 数据中心策略 1. 首先使用[管理托管](http://www.webhostingsearch.com/managed-web-hosting.php)提供程序。以信用卡为生，所以这是唯一的方法。 2. 托管托管无法随您扩展。您无法控制硬件或达成有利的网络协议。 3. 所以他们去了一个代管安排。现在，他们可以自定义所有内容并协商自己的合同。 4. 使用 5 或 6 个数据中心以及 CDN。 5. 视频来自任何数据中心。没有最接近的匹配或任何内容。如果视频足够受欢迎，它将移入 CDN。 6. 与视频带宽有关，而与延迟无关。可以来自任何 colo。 7. 对于图像延迟很重要，尤其是当页面上有 60 张图像时。 8. 使用 BigTable 将图像复制到不同的数据中心。代码查看不同的指标以了解谁最接近。 ## 得到教训 1. **停顿时间**。当您制定长期解决方案时，富有创意和冒险性的技巧可以帮助您在短期内应对。 2. **确定**的优先级。知道什么对您的服务至关重要，并根据这些优先级确定资源和工作的优先级。 3. **选择战斗**。不要害怕外包一些基本服务。 YouTube 使用 CDN 分发其最受欢迎的内容。创建自己的网络将花费很长时间并且花费太多。您的系统中可能会有类似的机会。查看[软件即服务](http://highscalability.com/tags/saas)，了解更多想法。 4. **保持简单！** 简单性使您可以更快地重新构造，以便可以对问题进行响应。确实没有人真正知道简单性是什么，但是如果您不害怕进行更改，那么这表明简单性正在发生。 5. **分片**。分片有助于隔离和限制存储，CPU，内存和 IO。这不仅仅是要获得更多的写入性能。 6. **瓶颈上的不断迭代**： -软件：数据库，缓存 -操作系统：磁盘 I / O -硬件：内存，RAID 7. **您作为一个团队**成功。拥有一支优秀的跨学科团队，了解整个系统以及系统的底层内容。可以设置打印机，机器，安装网络等的人员。一个好的团队，一切皆有可能。 [在[reduce]](http://www.reddit.com/r/programming/comments/2yfab3/the_youtube_architecture_2008/) 上。很棒的文章。非常感谢。 Dimitry。真正的目的是跳过两行：将受欢迎的内容保留在 CDN 上。换句话说，向 Akamai 扔钱，让 Akamai 担心。当然，这是正确的答案，但是无论您使用的是 Python 还是无关紧要的。如果没有 Akamai 的服务，鉴于上述基础架构，YouTube 将永远无法满足需求。 *-以信用卡为生，因此可以租用硬件。当他们需要更多硬件来处理负载时，花了几天时间订购并交付。* 这到底是如何工作的？当我们调查这个问题时，发现由于我们是一家新成立的初创公司，我们没有信誉（我想没有“发现”的意思，这很明显），因此硬件租赁公司只有在我们中一个人亲自支持贷款的情况下才会向我们出租。。鉴于启动风险高且费用高昂，我们最终购买了硬件并将其安装在各种低端 APR CC 等产品上。所有大型硬件供应商都表示“除非我们能看到您最近 N 年纳税申报表等，我们不会向您出租。” 使得租赁似乎不是“靠信用卡生存”创业公司的真正选择。哇，那是一篇很棒的文章，没想到 CDN：P 一定要接受红杉资本的私人风险投资，红杉资本也是 Google 的最大股东，并控制着其董事会。红杉资本利用其影响力迫使 Google 大量为 Youtube 多付钱，红杉资本合作伙伴立即获利 5 亿美元。这篇文章和视频对我正在从事的一些项目非常有希望。谢谢！完全令人惊叹; 100％值得一读。哇，真疯狂。一篇很好的文章，但我还没有学到任何新知识。当前的 YouTube 体系结构已被应用于我们的类似 youtube 用户的罗马尼亚网站之一，该网站称为 [http://www.trilulilu.ro/](http://www.trilulilu.ro/) 。我们的客户尚未实现的唯一一件事就是数据库分片，现在不需要了，因为 MySQL 数据库总数不到 250MB，而 MySQL 服务器处理的速度至少为 650 qps。那是一篇很棒的文章。我认为有趣的是，他们使用了 mod_fastcgi。我的意思是，我之所以使用它，是因为我被迫使用共享主机，但是在尝试进行大规模扩展时，我总是听说过很多问题（即使那是它的设计目标）。我想，如果做得对，FastCGI 对于服务器场可能是一笔宝贵的财富。这是一篇很棒的文章，非常有趣！很想听听更多这样的故事，例如 Flickr，Twitter，MySpace，Meebo ...客户仍然被大型企业参与者洗脑，认为他们需要 BEA Portal Server 或类似的东西来实现强大，可扩展的企业解决方案。要说服他们不要将钱花在昂贵的事情上，要花费大量时间来部署和花费巨额财富（并且要花费大量时间）以使其从用户体验的角度来做自己想做的事情，这是一场战斗。我一直在说：“ MySpace 每天注册 350,000 个用户，他们没有使用 Aqualogic-让我们为一些杀手级的 AJAX UI，小部件和一个实际上有用的 API 节省额外的现金。您靠个人信用卡为生，这是正确的...肯定也可以追溯到早期的 YouTube ... 谢谢你的好文章在 LAMP（Linux，Apache，MySQL，PHP）上组织 [http://anton.shevchuk.name/php/php-cookbook-myphptubecom/'](<a rel="nofollow" href="http://anton.shevchuk.name/php/php-cookbook-myphptubecom/) > MyPHPTube.com（YouTube 克隆）这是一本很棒的书，很好地证明了 Python 并不是它的慢速教练。在任何语言中，最大的挫折将永远是程序员的技能。很棒的文章。！是否有人知道在提升过程中必须使用的服务器数量的演变。？他们以多少开始，每台服务器具有哪种配置。还有他们正在使用哪个主机的任何想法。？谢谢谢谢！好的，那是有趣的信息，但是让我们停止将大量无序项目符号点称为“文章”吧？一篇文章有句子。可能分为几段。这是制作 Web 2.0 的一个很好的例子。记住那些在甲骨文，SUN 或其他大型公司上花费数百万美元来启动初创公司的邪恶旧时光，仅仅是为了使基本程序运行。现在，谁需要他们。有谁知道 Youtube 或 tinyURL 如何生成唯一 ID？他们在使用某种哈希函数吗？如果 URL 相同，tinyURL 不会生成唯一 ID。例如，对于 www.google.com，它总是生成 [http://tinyurl.com/1c2。](http://tinyurl.com/1c2.) 他们如何编码/解码 URL？我想我一直以为它们是预先分配的，所以它们总是最小且不可预测的，但是我找不到权威的答案。不过，这是一个有趣的问题。 TinyURL 需要一个代码映射-> URL，因此，当您键入 www.google.com 时，它将在其数据库中搜索该 URL，并为您提供先前生成的代码。是否有人知道在提升过程中必须使用的服务器数量的演变。？他们以多少开始，每台服务器具有哪种配置。 Also any idea which host they were using. ? 谢谢