你知道YouTube的架構是什麼嗎

閱讀提示：YouTube發展迅速，每天超過1億的視訊點選量，但只有很少人在維護站點和確保伸縮性。

YouTube發展迅速，每天超過1億的視訊點選量，但只有很少人在維護站點和確保伸縮性。

平臺

Apache
Python
Linux(SuSe)
MySQL
psyco，一個動態的Python到C的編譯器
lighttpd代替Apache做視訊檢視

狀態

支援每天超過1億的視訊點選量
成立於2005年2月
於2006年3月達到每天3千萬的視訊點選量
於2006年7月達到每天1億的視訊點選量
2個系統管理員，2個伸縮性軟體架構師
2個軟體開發工程師，2個網路工程師，1個DBA

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控制並注意其他低階問題
-調節每臺機器上的記憶體，不要太多也不要太少

視訊服務關鍵點

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。現在YouTube可以自定義所有東西並且協定自己的契約
4，使用5到6個資料中心加CDN
5，視訊來自任意的資料中心，不是最近的匹配或其他什麼。如果一個視訊足夠流行則移到CDN
6，依賴於視訊頻寬而不是真正的延遲。可以來自任何colo
7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時
8，使用BigTable將圖片備份到不同的資料中心，程式碼檢視誰是最近的

學到的東西

1，Stall for time。創造性和風險性的技巧讓你在短期內解決問題而同時你會發現長期的解決方案
2，Proioritize。找出你的服務中核心的東西並對你的資源分出優先順序別
3，Pick your battles。別怕將你的核心服務分出去。YouTube使用CDN來分佈它們最流行的內容。建立自己的網路將花費太多時間和太多money
4，Keep it simple！簡單允許你更快的重新架構來回應問題
5，Shard。Sharding幫助隔離儲存，CPU，記憶體和IO，不僅僅是獲得更多的寫效能
6，Constant iteration on bottlenecks：
-軟體：DB，快取
-OS：硬碟I/O
-硬體：記憶體，RAID
7，You succeed as a team。擁有一個跨越條律的瞭解整個系統並知道系統內部是什麼樣的團隊，如安裝印表機，安裝機器，安裝網路等等的人。With a good team all