# 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. ? 謝謝