YouTube發(fā)展迅速，每天超過1億的視頻點擊量，但只有很少人在維護站點和確保伸縮性。
平臺
Apache
Python
Linux(SuSe)
MySQL
psyco，一個動態(tài)的Python到C的編譯器
lighttpd代替Apache做視頻查看
狀態(tài)
支持每天超過1億的視頻點擊量
成立于2005年2月
于2006年3月達到每天3千萬的視頻點擊量
于2006年7月達到每天1億的視頻點擊量
2個系統(tǒng)管理員，2個伸縮性軟件架構師
2個軟件開發(fā)工程師，2個網(wǎng)絡工程師，1個DBA
處理飛速增長的流量
代碼
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}
每天運行該循環(huán)多次
Web服務器
1，NetScaler用于負載均衡和靜態(tài)內(nèi)容緩存
2，使用mod_fast_cgi運行Apache
3，使用一個Python應用服務器來處理請求的路由
4，應用服務器與多個數(shù)據(jù)庫和其他信息源交互來獲取數(shù)據(jù)和格式化html頁面
5，一般可以通過添加更多的機器來在Web層提高伸縮性
6，Python的Web層代碼通常不是性能瓶頸，大部分時間阻塞在RPC
7，Python允許快速而靈活的開發(fā)和部署
8，通常每個頁面服務少于100毫秒的時間
9，使用psyco(一個類似于JIT編譯器的動態(tài)的Python到C的編譯器)來優(yōu)化內(nèi)部循環(huán)
10，對于像加密等密集型CPU活動，使用C擴展
11，對于一些開銷昂貴的塊使用預先生成并緩存的html
12，數(shù)據(jù)庫里使用行級緩存
13，緩存完整的Python對象
14，有些數(shù)據(jù)被計算出來并發(fā)送給各個程序，所以這些值緩存在本地內(nèi)存中。這是個使用不當?shù)牟呗浴梅⻊掌骼镒羁斓木彺鎸㈩A先計算的值發(fā)送給所有服務器也花不了多少時間。只需弄一個代理來監(jiān)聽更改，預計算，然后發(fā)送。
視頻服務
1，花費包括帶寬，硬件和能源消耗
2，每個視頻由一個迷你集群來host，每個視頻被超過一臺機器持有
3，使用一個集群意味著：
-更多的硬盤來持有內(nèi)容意味著更快的速度
-failover。如果一臺機器出故障了，另外的機器可以繼續(xù)服務
-在線備份
4，使用lighttpd作為Web服務器來提供視頻服務：
-Apache開銷太大
-使用epoll來等待多個fds
-從單進程配置轉變?yōu)槎噙M程配置來處理更多的連接
5，大部分流行的內(nèi)容移到CDN：
-CDN在多個地方備份內(nèi)容，這樣內(nèi)容離用戶更近的機會就會更高
-CDN機器經(jīng)常內(nèi)存不足，因為內(nèi)容太流行以致很少有內(nèi)容進出內(nèi)存的顛簸
6，不太流行的內(nèi)容(每天1-20瀏覽次數(shù))在許多colo站點使用YouTube服務器
-長尾效應。一個視頻可以有多個播放，但是許多視頻正在播放。隨機硬盤塊被訪問
-在這種情況下緩存不會很好，所以花錢在更多的緩存上可能沒太大意義。
-調(diào)節(jié)RAID控制并注意其他低級問題
-調(diào)節(jié)每臺機器上的內(nèi)存，不要太多也不要太少
視頻服務關鍵點
1，保持簡單和廉價
2，保持簡單網(wǎng)絡路徑，在內(nèi)容和用戶間不要有太多設備
3，使用常用硬件，昂貴的硬件很難找到幫助文檔
4，使用簡單而常見的工具，使用構建在Linux里或之上的大部分工具
5，很好的處理隨機查找(SATA，tweaks)
縮略圖服務
1，做到高效令人驚奇的難
2，每個視頻大概4張縮略圖，所以縮略圖比視頻多很多
3，縮略圖僅僅host在幾個機器上
4，持有一些小東西所遇到的問題：
-OS級別的大量的硬盤查找和inode和頁面緩存問題
-單目錄文件限制，特別是Ext3，后來移到多分層的結構。內(nèi)核2.6的最近改進可能讓Ext3允許大目錄，但在一個文件系統(tǒng)里存儲大量文件不是個好主意
-每秒大量的請求，因為Web頁面可能在頁面上顯示60個縮略圖
-在這種高負載下Apache表現(xiàn)的非常糟糕
-在Apache前端使用squid，這種方式工作了一段時間，但是由于負載繼續(xù)增加而以失敗告終。它讓每秒300個請求變?yōu)?0個
-嘗試使用lighttpd但是由于使用單線程它陷于困境。遇到多進程的問題，因為它們各自保持自己單獨的緩存
-如此多的圖片以致一臺新機器只能接管24小時
-重啟機器需要6-10小時來緩存
5，為了解決所有這些問題YouTube開始使用Google的BigTable，一個分布式數(shù)據(jù)存儲：
-避免小文件問題，因為它將文件收集到一起
-快，錯誤容忍
-更低的延遲，因為它使用分布式多級緩存，該緩存與多個不同collocation站點工作
-更多信息參考Google Architecture，GoogleTalk Architecture和BigTable
數(shù)據(jù)庫
1，早期
-使用MySQL來存儲元數(shù)據(jù)，如用戶，tags和描述
-使用一整個10硬盤的RAID 10來存儲數(shù)據(jù)
-依賴于信用卡所以YouTube租用硬件
-YouTube經(jīng)過一個常見的革命：單服務器，然后單master和多read slaves，然后數(shù)據(jù)庫分區(qū)，然后sharding方式
-痛苦與備份延遲。master數(shù)據(jù)庫是多線程的并且運行在一個大機器上所以它可以處理許多工作，slaves是單線程的并且通常運行在小一些的服務器上并且備份是異步的，所以slaves會遠遠落后于master
-更新引起緩存失效，硬盤的慢I/O導致慢備份
-使用備份架構需要花費大量的money來獲得增加的寫性能
-YouTube的一個解決方案是通過把數(shù)據(jù)分成兩個集群來將傳輸分出優(yōu)先次序：一個視頻查看池和一個一般的集群
2，后期
-數(shù)據(jù)庫分區(qū)
-分成shards，不同的用戶指定到不同的shards
-擴散讀寫
-更好的緩存位置意味著更少的IO
-導致硬件減少30%
-備份延遲降低到0
-現(xiàn)在可以任意提升數(shù)據(jù)庫的伸縮性
數(shù)據(jù)中心策略
1，依賴于信用卡，所以最初只能使用受管主機提供商
2，受管主機提供商不能提供伸縮性，不能控制硬件或使用良好的網(wǎng)絡協(xié)議
3，YouTube改為使用colocation arrangement�，F(xiàn)在YouTube可以自定義所有東西并且協(xié)定自己的契約
4，使用5到6個數(shù)據(jù)中心加CDN
5，視頻來自任意的數(shù)據(jù)中心，不是最近的匹配或其他什么。如果一個視頻足夠流行則移到CDN
6，依賴于視頻帶寬而不是真正的延遲。可以來自任何colo
7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時
8，使用BigTable將圖片備份到不同的數(shù)據(jù)中心，代碼查看誰是最近的
學到的東西
1，Stall for time。創(chuàng)造性和風險性的技巧讓你在短期內(nèi)解決問題而同時你會發(fā)現(xiàn)長期的解決方案
2，Proioritize。找出你的服務中核心的東西并對你的資源分出優(yōu)先級別
3，Pick your battles。別怕將你的核心服務分出去。YouTube使用CDN來分布它們最流行的內(nèi)容。創(chuàng)建自己的網(wǎng)絡將花費太多時間和太多money
4，Keep it simple！簡單允許你更快的重新架構來回應問題
5，Shard。Sharding幫助隔離存儲，CPU，內(nèi)存和IO，不僅僅是獲得更多的寫性能
6，Constant iteration on bottlenecks：
-軟件：DB，緩存
-OS：硬盤I/O
-硬件：內(nèi)存，RAID
7，You succeed as a team。擁有一個跨越條律的了解整個系統(tǒng)并知道系統(tǒng)內(nèi)部是什么樣的團隊，如安裝打印機，安裝機器，安裝網(wǎng)絡等等的人。With a good team all things are possible。