這篇文章主要介紹了YouTube網站用到的技術架構及擴展經驗,作為全球最大在線視頻網站的YouTube一直堅持簡潔的架構原則并且在可擴展性方面做得相當出色,需要的朋友可以參考下

YouTube發展迅速，每天超過1億的視頻點擊量，但只有很少人在維護站點和確保伸縮性。這點和PlentyOfFish類似，少數人維護龐大系統。是什么原因呢？放心絕對不是靠人品，也不是靠寂寞，下面就來看看YouTube的整體技術架構吧。

平臺

Apache

Python

Linux(SuSe)

MySQL

psyco，一個動態的Python到C的編譯器

lighttpd代替Apache做視頻查看</strong>

狀態

支持每天超過1億的視頻點擊量

成立于2005年2月

于2006年3月達到每天3千萬的視頻點擊量

于2006年7月達到每天1億的視頻點擊量

2個系統管理員，2個伸縮性軟件架構師

2個軟件開發工程師，2個網絡工程師，1個DBA</strong>

Web服務器

1，NetScaler用于負載均衡和靜態內容緩存

2，使用mod_fast_cgi運行Apache

3，使用一個Python應用服務器來處理請求的路由

4，應用服務器與多個數據庫和其他信息源交互來獲取數據和格式化html頁面

5，一般可以通過添加更多的機器來在Web層提高伸縮性

6，Python的Web層代碼通常不是性能瓶頸，大部分時間阻塞在RPC

7，Python允許快速而靈活的開發和部署

8，通常每個頁面服務少于100毫秒的時間

9，使用psyco(一個類似于JIT編譯器的動態的Python到C的編譯器)來優化內部循環

10，對于像加密等密集型CPU活動，使用C擴展

11，對于一些開銷昂貴的塊使用預先生成并緩存的html

12，數據庫里使用行級緩存

13，緩存完整的Python對象

14，有些數據被計算出來并發送給各個程序，所以這些值緩存在本地內存中。這是個使用不當的策略。

應用服務器里最快的緩存將預先計算的值發送給所有服務器也花不了多少時間。只需弄一個代理來監聽更改，預計算，然后發送。

視頻服務

1，花費包括帶寬，硬件和能源消耗

2，每個視頻由一個迷你集群來host，每個視頻被超過一臺機器持有

3，使用一個集群意味著：

-更多的硬盤來持有內容意味著更快的速度

-failover。如果一臺機器出故障了，另外的機器可以繼續服務

-在線備份

4，使用lighttpd作為Web服務器來提供視頻服務：

-Apache開銷太大

-使用epoll來等待多個fds

-從單進程配置轉變為多進程配置來處理更多的連接

5，大部分流行的內容移到CDN：

-CDN在多個地方備份內容，這樣內容離用戶更近的機會就會更高

-CDN機器經常內存不足，因為內容太流行以致很少有內容進出內存的顛簸

6，不太流行的內容(每天1-20瀏覽次數)在許多colo站點使用YouTube服務器

-長尾效應。一個視頻可以有多個播放，但是許多視頻正在播放。隨機硬盤塊被訪問

-在這種情況下緩存不會很好，所以花錢在更多的緩存上可能沒太大意義。

-調節RAID控制并注意其他低級問題

-調節每臺機器上的內存，不要太多也不要太少 </strong>

視頻服務關鍵點

1，保持簡單和廉價

2，保持簡單網絡路徑，在內容和用戶間不要有太多設備

3，使用常用硬件，昂貴的硬件很難找到幫助文檔

4，使用簡單而常見的工具，使用構建在Linux里或之上的大部分工具

5，很好的處理隨機查找(SATA，tweaks)

縮略圖服務

1，做到高效令人驚奇的難

2，每個視頻大概4張縮略圖，所以縮略圖比視頻多很多

3，縮略圖僅僅host在幾個機器上

4，持有一些小東西所遇到的問題：

-OS級別的大量的硬盤查找和inode和頁面緩存問題

-單目錄文件限制，特別是Ext3，后來移到多分層的結構。內核2.6的最近改進可能讓 Ext3允許大目錄，但在一個文件系統里存儲大量文件不是個好主意

-每秒大量的請求，因為Web頁面可能在頁面上顯示60個縮略圖

-在這種高負載下Apache表現的非常糟糕

-在Apache前端使用squid，這種方式工作了一段時間，但是由于負載繼續增加而以失敗告終。它讓每秒300個請求變為20個

-嘗試使用lighttpd但是由于使用單線程它陷于困境。遇到多進程的問題，因為它們各自保持自己單獨的緩存

-如此多的圖片以致一臺新機器只能接管24小時

-重啟機器需要6-10小時來緩存

5，為了解決所有這些問題YouTube開始使用Google的BigTable，一個分布式數據存儲：

-避免小文件問題，因為它將文件收集到一起

-快，錯誤容忍

-更低的延遲，因為它使用分布式多級緩存，該緩存與多個不同collocation站點工作

-更多信息參考Google Architecture，GoogleTalk Architecture和BigTable

數據庫

1，早期

-使用MySQL來存儲元數據，如用戶，tags和描述

-使用一整個10硬盤的RAID 10來存儲數據

-依賴于信用卡所以YouTube租用硬件

-YouTube經過一個常見的革命：單服務器，然后單master和多read slaves，然后數據庫分區，然后sharding方式

-痛苦與備份延遲。master數據庫是多線程的并且運行在一個大機器上所以它可以處理許多工作，slaves是單線程的并且通常運行在小一些的服務器上并且備份是異步的，所以slaves會遠遠落后于master

-更新引起緩存失效，硬盤的慢I/O導致慢備份

-使用備份架構需要花費大量的money來獲得增加的寫性能

-YouTube的一個解決方案是通過把數據分成兩個集群來將傳輸分出優先次序：一個視頻查看池和一個一般的集群

2，后期

-數據庫分區

-分成shards，不同的用戶指定到不同的shards

-擴散讀寫

-更好的緩存位置意味著更少的IO

-導致硬件減少30%

-備份延遲降低到0

-現在可以任意提升數據庫的伸縮性

數據中心策略

1，依賴于信用卡，所以最初只能使用受管主機提供商

2，受管主機提供商不能提供伸縮性，不能控制硬件或使用良好的網絡協議

3，YouTube改為使用colocation arrangement?，F在YouTube可以自定義所有東西并且協定自己的契約

4，使用5到6個數據中心加CDN

5，視頻來自任意的數據中心，不是最近的匹配或其他什么。如果一個視頻足夠流行則移到CDN

6，依賴于視頻帶寬而不是真正的延遲?？梢詠碜匀魏蝐olo

7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時

8，使用BigTable將圖片備份到不同的數據中心，代碼查看誰是最近的

關于擴展性的思考

以下雖然都不是什么新思想，但希望對你有所助益。

分而治之是擴展性技術的靈魂。考慮以層次化的方式完成所有的工作。這也是數據分片的癥結所在。要知道如何將數據分區，以及如何將已分區的數據進行關聯?？偠灾３趾唵闻c松散的耦合非常必要。

充分利用Python的動態特性，構建易于擴展的軟件架構。

近似的正確性。要相信監控系統所報告的系統運行狀態。如果問題沒有出現，就認為一切良好。

不一致的數據模型。例如，閱讀評論的人和寫評論的人對你刷新頁面的動作會有不同的反應，但也不必完全基于事務處理進行系統設計，這會顯得矯枉過正。我們依然需要不一致的數據模型。

分布式系統的隨機性。分布式系統就如同氣象系統一樣，對分布式系統進行調試會存在更多的隨機性。例如，緩存過期。一般情況下，服務器會將流行的視頻緩存24小時。如果一旦出現緩存同時過期的情況，服務器將同時開始緩存，荷載如聞驚雷！

最快的函數調用就是不做任何調用。合理設計事務處理發生的間隔和次數。

仔細觀察API，并做到心中有數。如何定義輸入、輸出？所有的函數調用本質上都是圍繞數據發生的，那在函數調用之后，又會發生什么？

在Python中運用RPC重定向。程序員是代碼的構建者，因此要做好約定。如果代碼不幸失敗了，還可以從RPC輸出中追查原因。

沒有完美的組件。一個組件的運行周期可能持續1-6個月，具體多久，誰也說不清。隨著時間的推移，我們會用Python和C重寫一些東西，這證明你正在淘汰舊的組件，當你觀察到一個新組件出現的時候，它誕生了。

沒有人了解整個系統的運作機制。因此，我們需要定義組件。視頻轉碼和視頻搜索截然不同，建立良好的數據規范非常重要。

效率與擴展性并重。最有效率的是用C實現進程，但這樣的方式缺乏擴展性。

著眼于宏觀層面、組件及其失敗的原因。使用RPC是否明智？內聯如何？進行分解研究，也許會發現不同之處。

重視算法。與其絞盡腦汁用Python來實現高效的算法，不如用它做些更有實用價值的事。在這方面，C語言有它的優勢。

我們很少從事面向對象設計。我們使用了大量的名稱空間，使用類來組織數據，但極少面向對象。

我樂意用下面的詞匯來形容我們的代碼樹：簡單、實用、優雅、正交、可組合，這是我們的追求。

總結

YouTube解決問題的哲學只有一個詞：簡單。許多YouTube的產品最初只是源于一個簡單的Python腳本。這正是應了我們的一句老話，不積跬步，無以至千里；不積小流，無以成江海。