這幾天一直在關注和學習一些大型網站的架構，希望有一天自己也能設計一個高併發、高容錯的系統並能應用在實踐上。今天在網上找架構相關的資料時，看到一個被和諧的視頻網站YouTube的架構分析，看了以後覺得自己又向架構走近了一步，於是趕快拿出來與大家一起分享。
YouTube發展迅速，每天超過1億的視頻點擊量，但只有很少人在維護站點和確保伸縮性。這點和PlentyOfFish類似，少數人維護龐大系統。是什麼原因呢？放心絕對不是靠人品，也不是靠寂寞，下面就來看看YouTube的整體技術架構吧。
平臺
|
1
2
3
4
5
6
|
<strong>ApachePythonLinux(SuSe)MySQLpsyco，一個動態的Python到C的編譯器lighttpd代替Apache做視頻查看</strong> |
狀態
|
1
2
3
4
5
6
|
<strong>支持每天超過1億的視頻點擊量成立於2005年2月於2006年3月達到每天3千萬的視頻點擊量於2006年7月達到每天1億的視頻點擊量2個系統管理員，2個伸縮性軟件架構師2個軟件開發工程師，2個網絡工程師，1個DBA</strong> |
Web服務器
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<strong>1，NetScaler用於負載均衡和靜態內容緩存2，使用mod_fast_cgi運行Apache3，使用一個Python應用服務器來處理請求的路由4，應用服務器與多個數據庫和其他信息源交互來獲取數據和格式化html頁面5，一般可以通過添加更多的機器來在Web層提高伸縮性6，Python的Web層代碼通常不是性能瓶頸，大部分時間阻塞在RPC7，Python允許快速而靈活的開發和部署8，通常每個頁面服務少於100毫秒的時間9，使用psyco(一個類似於JIT編譯器的動態的Python到C的編譯器)來優化內部循環10，對於像加密等密集型CPU活動，使用C擴展11，對於一些開銷昂貴的塊使用預先生成並緩存的html12，數據庫裏使用行級緩存13，緩存完整的Python對象14，有些數據被計算出來併發送給各個程序，所以這些值緩存在本地內存中。這是個使用不當的策略。 應用服務器裏最快的緩存將預先計算的值發送給所有服務器也花不了多少時間。只需弄一個代理來監聽更改，預計算，然後發送。</strong> |
視頻服務
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
<strong>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
5
|
1，保持簡單和廉價2，保持簡單網絡路徑，在內容和用戶間不要有太多設備3，使用常用硬件，昂貴的硬件很難找到幫助文檔4，使用簡單而常見的工具，使用構建在Linux裏或之上的大部分工具5，很好的處理隨機查找(SATA，tweaks) |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
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
4
5
6
7
8
|
1，依賴於信用卡，所以最初只能使用受管主機提供商2，受管主機提供商不能提供伸縮性，不能控制硬件或使用良好的網絡協議3，YouTube改爲使用colocation arrangement。現在YouTube可以自定義所有東西並且協定自己的契約4，使用5到6個數據中心加CDN5，視頻來自任意的數據中心，不是最近的匹配或其他什麼。如果一個視頻足夠流行則移到CDN6，依賴於視頻帶寬而不是真正的延遲。可以來自任何colo7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時8，使用BigTable將圖片備份到不同的數據中心，代碼查看誰是最近的 |
|
1
2
3
4
5
6
7
8
9
10
11
|
1，Stall for time。創造性和風險性的技巧讓你在短期內解決問題而同時你會發現長期的解決方案2，Proioritize。找出你的服務中核心的東西並對你的資源分出優先級別3，Pick your battles。別怕將你的核心服務分出去。YouTube使用CDN來分佈它們最流行的內容。創建自己的網絡將花費太多時間和太多money4，Keep it simple！簡單允許你更快的重新架構來回應問題5，Shard。Sharding幫助隔離存儲，CPU，內存和IO，不僅僅是獲得更多的寫性能6，Constant iteration on bottlenecks： -軟件：DB，緩存 -OS：硬盤I/O -硬件：內存，RAID7，You succeed as a team。擁有一個跨越條律的瞭解整個系統並知道系統內部是什麼樣的團隊，如安裝打印機，安裝機器，安裝網絡等等的人。 With a good team all things are possible。 |