【從一台 Server 到分散式架構】第 26 篇：用同樣的思維看 YouTube——大規模影片系統
小明把課程平台的架構整理完之後，朋友問了他一個問題：
「那 YouTube 是怎麼做的？每天上傳幾百萬部影片、幾十億人次觀看，他們的架構是什麼樣子？」
小明想了一下，說：「我覺得我可以用現在學到的東西來推導一遍。」
YouTube 的規模（量級感受）
先感受一下規模：
- 每分鐘上傳 500 小時的影片
- 每天有 20 億登入用戶
- 每天觀看次數超過 10 億小時
這個規模，很多問題的解法和小明的課程平台是一樣的——只是量大了幾個數量級，每個環節都要放大。
把 YouTube 拆成幾個子問題
系統設計的第一步：把大問題拆成小問題。
YouTube 可以拆成：
- 上傳流程：影片怎麼傳進來、怎麼轉檔
- 儲存：這麼多影片放在哪裡
- 播放：影片怎麼讓全球的人順暢看
- 元資料：影片標題、觀看數、留言——用什麼資料庫
- 搜尋：關鍵字找影片
- 推薦：首頁、下一部影片推什麼
- 讀多寫少：觀看遠多於上傳，架構要怎麼設計
上傳流程：非同步處理是核心
用戶上傳一部影片後，要做很多事：
- 轉檔成多種解析度（4K、1080p、720p、480p、360p）
- 生成縮圖
- 做音訊分離
- 做字幕生成
- 病毒掃描
- 版權偵測
這些任務不可能同步處理——用戶等你把 4K 轉完才收到「上傳成功」，要等幾十分鐘。
做法：非同步佇列（和第 07-08 篇完全一樣的概念）
用戶上傳影片
→ 原始檔案先存入物件儲存（Object Storage）
→ 立刻回傳「上傳成功，處理中」
→ 佇列通知各個 Worker 開始處理
→ 轉檔 Worker（可多台並行）開始轉各種解析度
→ 每個解析度轉完就存入 Object Storage
→ 更新元資料 DB：「這個影片的 1080p 版本可以看了」
轉檔是 CPU 密集型任務，可以把多個解析度並行轉，加快速度。
儲存：影片不能放在一般資料庫
一部 1080p、10 分鐘的影片，大約是 1-2 GB。一般關聯式資料庫不適合存這種大型二進位檔案。
解法：物件儲存（Object Storage）
- AWS S3、Google Cloud Storage、Azure Blob Storage
- 設計來儲存「大量、大尺寸的二進位物件」
- 幾乎無限擴展、高耐久性（通常有三份副本）
- 按用量計費，不需要管硬體
YouTube 的影片本體存在類似 S3 的物件儲存；影片的元資料（標題、描述、觀看數、上傳者）存在資料庫。
播放：CDN 是關鍵
觀看影片有一個特性：讀遠大於寫，而且同一部熱門影片會被全球反覆觀看。
如果每個請求都從中央伺服器讀影片，不但慢（物理距離），而且中央頻寬爆了。
解法：CDN（Content Delivery Network，內容傳遞網路）
CDN 在全球各地有節點（Edge Node）。熱門影片會被快取到距離用戶最近的節點：
台灣用戶看影片
→ 先去台灣 CDN 節點找
→ 有快取 → 直接從台灣節點傳輸（快）
→ 沒快取 → 去中央伺服器拿，同時快取到台灣節點
→ 下一個台灣用戶看同一部影片 → 直接從 CDN 拿
CDN 的效果：
- 延遲降低（物理距離近）
- 中央伺服器負擔大幅降低（熱門影片幾乎全從 CDN 拿）
- 全球用戶體驗均等
元資料：哪種資料庫放哪種資料
YouTube 有多種資料，每種適合不同的儲存：
| 資料 | 特性 | 適合的儲存 |
|---|---|---|
| 影片元資料（標題、描述、頻道） | 結構化、需要關聯 | 關聯式 DB（MySQL / PostgreSQL） |
| 觀看數、按讚數 | 極高寫入頻率 | 計數器 + 批次寫入（Redis + 週期 flush 到 DB） |
| 留言 | 大量、非結構化 | 文件型 DB（Cassandra / MongoDB） |
| 搜尋 | 全文搜尋、關鍵字相關度 | Elasticsearch（第 16 篇） |
| 觀看記錄、播放時間 | 時序流水帳 | 大數據平台（Bigtable / Cassandra） |
觀看數值得特別說：YouTube 每秒的觀看次數是幾百萬——如果每次觀看都直接 +1 寫入資料庫，DB 早就炸了。
做法：先存 Redis 計數，定期批次寫進 DB。用戶看到的觀看數可能比真實數字少幾分鐘，但這是可以接受的「最終一致性（第 10 篇 CAP 理論的 A）」。
搜尋：和課程平台一樣的解法
YouTube 的搜尋原理和第 16 篇的 Elasticsearch 一樣：
- 影片上傳後，標題、描述、字幕的文字內容被索引進搜尋引擎
- 用戶搜尋 → 全文搜尋 + 相關度排序
- 加上個人化：你的搜尋歷史、訂閱頻道會影響排序
推薦：這是最複雜的部分
YouTube 首頁的推薦系統（「下一部影片」那個），是 YouTube 的核心競爭力，也是整個系統裡最複雜的部分——這不是本系列要深入的範圍（涉及機器學習），但架構上的概念是：
- 離線計算：定期對用戶的觀看記錄、按讚記錄做模型訓練，生成「推薦列表」存起來
- 線上服務：用戶打開 YouTube → 取出預先算好的推薦列表 → 顯示
分離「計算」和「服務」：計算昂貴但可以非同步；服務要快，讀預算好的結果。
用架構思維整理 YouTube
小結
YouTube 的架構沒有魔法，它是我們走過的這些思維的組合：
- 非同步佇列：上傳後不等轉檔完成
- 物件儲存：大型二進位檔案的歸宿
- CDN：全球化讀取加速，讀多寫少的極致
- 多種資料庫：不同資料選不同工具（第 16 篇）
- 最終一致性：觀看數不用即時精確，可接受短暫延遲
下一篇，我們換個場景：Uber 的即時派車系統——有位置、有時間、有大量寫入，完全不同的挑戰。