面試題 | 設計youtube

Use Cases

• 上傳 視頻

• 分享/查看 視頻

• 基於title搜索

• 記錄視頻狀態：贊/踩，播放數量

• 評論

• 高可靠

• 高可用AP

• 低時延，不卡頓

約束

• 500M用戶，DAU 1M
• 單條視頻100MB，1M/day，存儲=100TB，上傳qps=11.3
• 視頻 r/w = 100/1， 讀qps=1100
• 評論 10M ，每條1KB 存儲 10G，qps=110
• 存儲增長：100TB / 3PB / 36PB / 180PB
• 元數據：vedio / comment/ user 易擴展

High Level

1. upload服務 app server：負責任務轉發和路由，上傳任務放到隊列，用戶註冊讀寫User DB，查看和評論任務讀寫metadata DB
2. 消息隊列：上傳視頻先push到隊列，然後被消費（編碼/生成縮略圖/存儲）
3. 轉碼服務：離線轉碼到多個碼率，多種格式
4. 縮略圖生成服務
5. video和縮略圖存儲：分佈式存儲
6. video metadata storage：存儲視頻元信息和評論:title/filePath/user/total views/like/dislike
7. User DB：存儲用戶信息

DB schema

詳細設計

1. 如何處理大量讀video？

• 讀寫分離：服務層面分離upload服務；video存儲多副本，分散讀取壓力；metadata 主從MS架構，寫master，讀取slave節點；
  • 問題：主從會導致staleness問題，slave節點因同步有延遲，但是在youtube系統可以容忍，用戶幾毫秒後，可以看到新視頻；

2.如何處理縮略圖大量讀？

• 存儲：小文件(<5KB)大量讀(qps=20K)的存儲 - bigtable
• 存儲如何選型
  • 合併小文件，減少文件次數，提升seek效率
  • 優化小文件讀IO
• 讀取優化：熱點文件的cache，小文件，內存cache

3. 視頻如何存儲？

• 分佈式文件系統 HDFS

4. 圖片上傳的效率優化？

• 支持斷點續傳

Scale

• cache/cdn/LB
  • 熱點視頻會導致cache servers的負載不均勻，如何解決？
    • 多副本，busy server重定向到less busy servers
      • 重定向的問題？
        • 可能導致多次重定向
        • 增大了時延，視頻播放變慢
        • 跨數據中心的重定向可能導致服務變慢
• deplication
• sharding：用userID的缺點1）熱點user影響同server的其他用戶 2）存儲不均勻；
  • 用videoID代替userID，用cache解決熱點video的問題；查詢某個userID的視頻時，從多個server獲取視頻，再交由一箇中心server彙總和排序；

總結

系統最關鍵的點：縮略圖如何存儲？

• 讀圖/視頻 = 20/1
• bigtable適合存儲大量讀的小文件，在讀方面做了很多優化，需要研究下