YouTube的架構擴充套件

在西雅圖擴充套件性的技術研討會上，YouTube 的 Cuong Do 做了關於 YouTube Scalability 的報告。影片內容在 Google Video 上有(地址)，可惜國內使用者看不到。

　　Kyle Cordes 對這個影片中的內容做了介紹。裡面有不少技術性的內容。值得分享一下。(Kyle Cordes 的介紹是本文的主要來源)

　　簡單的說 YouTube 的資料流量, "一天的YouTube流量相當於傳送750億封電子郵件.", 2006 年中就有訊息說每日 PV 超過 1 億,現在? 更誇張了,"每天有10億次下載以及6,5000次上傳", 真假姑且不論, 的確是超乎尋常的海量.

[@more@]1.Web伺服器

　　YouTube 出於開發速度的考慮，大部分程式碼都是 Python 開發的。Web 伺服器有部分是 Apache， 用 FastCGI 模式。對於影片內容則用 Lighttpd 。據我所知，MySpace 也有部分伺服器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(國內用 Lighttpd 站點不多，豆瓣用的比較舒服。by Fenng)

　　2.影片

　　影片的縮圖(Thumbnails)給伺服器帶來了很大的挑戰。每個影片平均有4個縮圖，而每個 Web 頁面上更是有多個，每秒鐘因為這個帶來的磁碟 IO 請求太大。YouTube 技術人員啟用了單獨的伺服器群組來承擔這個壓力，並且針對 Cache 和 OS 做了部分最佳化。另一方面，縮圖請求的壓力導致 Lighttpd 效能下降。透過 Hack Lighttpd 增加更多的 worker 執行緒很大程度解決了問題。而最新的解決方案是起用了 Google 的 BigTable， 這下子從效能、容錯、快取上都有更好表現。看人家這收購的，好鋼用在了刀刃上。

　　出於冗餘的考慮，每個影片檔案放在一組迷你 Cluster 上，所謂 "迷你 Cluster" 就是一組具有相同內容的伺服器。最火的影片放在 CDN 上，這樣自己的伺服器只需要承擔一些"漏網"的隨即訪問即可。YouTube 使用簡單、廉價、通用的硬體，這一點和 Google 風格倒是一致。至於維護手段，也都是常見的工具，如 rsync, SSH 等，只不過人家更手熟罷了。

　　3.資料庫

　　YouTube 用 MySQL 儲存後設資料--使用者資訊、影片資訊什麼的。資料庫伺服器曾經一度遇到 SWAP 顛簸的問題，解決辦法是刪掉了 SWAP 分割槽! 管用。

　　最初的 DB 只有 10 塊硬碟，RAID 10 ，後來追加了一組 RAID 1。夠省的。這一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,參見這裡). 在擴充套件性方面，路線也是和其他站點類似，複製，分散 IO。最終的解決之道是"分割槽",這個不是資料庫層面的表分割槽，而是業務層面的分割槽(在使用者名稱字或者 ID 上做文章,應用程式控制查詢機制)

　　YouTube 也用 Memcached.