14
SYSTEM DESIGN INTERVIEW · CHAPTER 14

設計 YouTube

大規模影片串流服務的系統設計
《內行人才知道的系統設計面試指南》
前言 · YouTube 的真實規模
02 / 31

YouTube 的真實規模

2020 年公開數據 — 為什麼面試官愛問這題

月活躍使用者（MAU）
20億
每日觀看影片數
50億
美國成年人使用率
73%
創作者數量
5,000萬
2019 廣告收入
$151億 USD
年增 36%
佔行動上網流量
37%
支援語言
80種
平均每秒播放請求（推估）
≈ 5.8萬 / 秒
50 億 ÷ 86,400 秒
「YouTube 是巨大的、全球性的，並且賺了很多錢。」
Step 1 · 釐清需求
03 / 31

Step 1 · 本章設計目標

候選人先問問題、再縮小範圍，聚焦在核心功能

候選人問了哪些問題（書中對話精簡）
重點功能？
上傳 + 觀看
客戶端？
App / 瀏覽器 / TV
DAU？
500 萬
國際使用者？
是
加密？
是
影片上限？
1 GB
雲服務？
鼓勵使用
本章專注設計具備以下 6 大特性的影片串流服務
01
快速上傳影片的能力
02
流暢的影片串流
03
能夠改變影片的品質
04
基礎設施成本低
05
高可用性、可擴展性與可靠性
06
支援行動 App、瀏覽器、智慧電視
本頁名詞速覽
  • 日活躍使用者（Daily Active Users, DAU）　每天至少使用一次的使用者數
Step 1 · 粗略估算
04 / 31

Step 1 · 粗略估算

每天需要多少儲存？CDN 要花多少錢？

儲存估算 · 每日新增資料量
基礎假設：500 萬 DAU、10% 使用者每日上傳 1 部、平均影片 300 MB
500 萬 × 10% × 300 MB
= 150 TB / 天
CDN 成本估算 · 每日影片串流
假設每人每日觀看 5 部影片、每部約 0.3 GB、100% 流量來自美國、CloudFront 每 GB 約 $0.02 USD
500 萬 × 5 部 × 0.3 GB × $0.02
= $150,000 / 天
「從粗略的成本估算中，我們知道從 CDN 提供影片的成本很高。即使雲端供應商願意為大客戶大幅降低 CDN 成本，但成本仍然很高。我們將深入討論降低 CDN 成本的方法。」
CloudFront pricing
本頁名詞速覽
  • 內容分發網路（Content Delivery Network, CDN）　全球分布的伺服器網路，把內容快取在離使用者較近的節點
Step 2 · 提出高層設計
05 / 31

Step 2 · 為什麼利用現有雲服務？

不要重新發明輪子

理由 1　面試的重點是「選對工具」
系統設計面試並不是要從頭開始建立一切。在有限的時間內，選擇正確的技術來做好一項工作，比詳細解釋技術的工作原理更重要。例如，提到用來儲存原始影片的 BLOB 儲存就足以應付面試了，談論 BLOB 儲存的詳細設計可能是矯枉過正。
理由 2　連大公司都不自己造
建構可擴展的 BLOB 儲存或 CDN 是非常複雜且昂貴的。即使像 Netflix 或 Facebook 這樣的大公司也不會自己建立一切：
  • Netflix 利用 Amazon 的雲端服務（AWS）
  • Facebook 使用 Akamai 的 CDN
本章將利用的兩項雲服務
CDN
BLOB 儲存
本頁名詞速覽
  • 二進位大物件（Binary Large Object, BLOB）　在資料庫管理系統中作為單一實體儲存的二進位資料集合
  • Akamai　全球最大的 CDN 服務提供商之一
Step 2 · 高層設計
06 / 31

Step 2 · 高層架構：三大組件

影片走 CDN、其他全走 API 伺服器

figure 14-3
Client　客戶端
你可以在電腦、手機和智慧電視上觀看 YouTube。
CDN　內容分發網路
影片被儲存在 CDN 中。當你按下播放鍵時，影片就會從 CDN 上串流下來。
API Servers　API 伺服器
除了影片串流之外的所有其他內容都通過 API 伺服器，包括：推薦動態、生成影片上傳 URL、更新 metadata 資料庫與快取、使用者註冊…等。
→ 面試官特別感興趣的兩個流程：影片上傳流程　&　影片串流流程
本頁名詞速覽
  • API 伺服器（API Servers）　處理應用程式邏輯與請求的後端伺服器
Step 2 · 上傳流程
07 / 31

上傳流程的完整元件

影片走一條線、metadata 走另一條線

figure 14-4
使用者　在電腦/手機/智慧電視觀看 YouTube
負載平衡器　在 API 伺服器之間均勻分配請求
API 伺服器　除影片串流外的所有使用者請求都通過它
元資料資料庫　儲存影片 metadata，分片並複製
元資料快取　快取影片 metadata 與使用者物件
原始儲存系統　BLOB 儲存，存放原始影片
轉碼伺服器　影片轉碼=影片編碼，從一種格式轉成多種格式
已轉碼儲存系統　BLOB 儲存，存放轉碼影片檔案
CDN　影片被快取在 CDN 中
完成事件佇列　訊息佇列，儲存轉碼完成事件
完成處理器　一組工作者，從完成事件佇列提取事件並更新元資料快取與資料庫
本頁名詞速覽
  • 負載平衡器（Load Balancer）　把請求平均分配給多台伺服器的中介裝置
  • 元資料資料庫（Metadata DB）　儲存影片描述資料的資料庫；元資料快取（Metadata Cache）　其記憶體層快取
  • 原始儲存系統（Original Storage）　原始影片的 BLOB 儲存；已轉碼儲存系統（Transcoded Storage）　轉碼後影片的 BLOB 儲存
  • 分片（Sharding）　把資料切分成多個資料庫實例；訊息佇列（Message Queue）　暫存訊息、讓生產者與消費者解耦的中介系統
Step 2 · 上傳流程 1
08 / 31

上傳流程 1：上傳真正的影片

3a / 3b 平行展開，是這個流程的精髓

figure 14-5
  • 1
    影片被上傳到原始儲存系統
  • 2
    轉碼伺服器從原始儲存系統中取得影片並開始轉碼
  • 3
    一旦轉碼完成，以下兩步平行執行：
  • 3a
    轉碼後的影片被送到已轉碼儲存系統
  • 3b
    轉碼完成事件被排在完成事件佇列中
  • 3a.1
    轉碼後的影片被分發到 CDN
  • 3b.1
    完成處理器包含一群工作者，不斷從佇列中提取事件資料
  • 3b.1.a
    完成處理器更新 Metadata DB（元資料資料庫）
  • 3b.1.b
    完成處理器更新 Metadata Cache（元資料快取）
  • 4
    API 伺服器通知客戶端：影片已成功上傳，可以開始串流播放
本頁名詞速覽
  • 轉碼（Transcoding）　把影片從一種格式轉成多種其他格式（不同畫質、不同協定）的過程
  • 完成事件佇列（Completion Queue）　訊息佇列，存放「轉碼完成」事件，解耦上傳、轉碼、CDN 推送
Step 2 · 上傳流程 2
09 / 31

上傳流程 2：更新影片 Metadata

與影片本體「同時」進行的另一條平行線

figure 14-6
同步發出的請求
當檔案被上傳到原始儲存系統時，客戶端會同時發送一個「更新影片 metadata」的請求，內容包含：
  • 檔名（Filename）
  • 大小（Size）
  • 格式（Format）
  • 其他相關資訊
API 伺服器收到後，同步更新兩處
Metadata Cache Metadata DB
為什麼要平行？　影片本體很大（最多 1 GB）、上傳時間長；metadata 很小、可以馬上寫入。讓兩者分開進行，metadata 能立刻被查詢（例如顯示「上傳中」狀態），不必等影片傳完。
本頁名詞速覽
  • 元資料（Metadata）　描述資料的資料（檔名、大小、格式、上傳者等）
Step 2 · 影片串流流程
10 / 31

影片串流是什麼？跟下載有什麼不同？

大型影片平台必須採用「邊看邊載」

Downloading

下載

  • 整支影片被複製到你的設備上
  • 必須等檔案下載完成才能播放
  • 整支影片離線可用
想像 1 GB 的影片要等下載完才能看，使用者體驗會非常糟糕。
Streaming

串流

  • 你的設備不斷接收來自遠端的影片流
  • 客戶端每次只載入一小段資料
  • 因此可以立即且連續地觀看影片
串流不需要把整支影片複製到使用者裝置，而是邊看邊載。
本頁名詞速覽
  • 串流（Streaming）　邊接收邊播放的資料傳輸方式
  • 下載（Downloading）　把完整檔案複製到本機後再使用
Step 2 · 串流協定
11 / 31

串流協定與串流流程

協定名字不用背、知道有就好

4 種主流串流協定
MPEG-DASH
MPEG = Moving Pictures Experts Group
DASH = Dynamic Adaptive Streaming over HTTP
Apple HLS
HLS = HTTP Live Streaming（HTTP 即時串流）
Microsoft Smooth Streaming
微軟的串流協定
Adobe HDS
HDS = HTTP Dynamic Streaming（HTTP 動態串流）
「你不需要完全理解甚至記住這些串流協定的名稱，因為它們是需要特定領域知識的低層次細節。重要的是要明白：不同的串流協定支援不同的影片編碼與播放器。當我們設計影片串流服務時，必須選擇正確的串流協定來支援我們的使用案例。」
串流流程
影片直接從 CDN 串流，離使用者最近的邊緣伺服器（Edge Server）會提供影片。因此延遲非常小。
figure 14-7
本頁名詞速覽
  • 串流協定（Streaming Protocol）　控制串流資料傳輸的標準化方式
  • 邊緣伺服器（Edge Server）　CDN 中分布在世界各地、離使用者最近的伺服器節點
Step 3 · 影片轉碼
12 / 31

Step 3 · 影片轉碼基本概念

從比特率（Bitrate）說起

比特率（Bitrate）的定義
比特率是指隨著時間推移、比特被處理的速度。更高的比特率通常意味著更高的影片品質。高比特率的串流需要更多的處理能力和快速的網路速度。
為什麼需要關心比特率？
當你錄製影片時，設備會給檔案一個格式。如果你想讓影片在其他設備上順利播放，影片必須被編碼為相容的比特率與格式。
典型比特率參考（補充常識）
480p≈ 1 Mbps
720p≈ 2.5 Mbps
1080p≈ 5 Mbps
4K≈ 20 Mbps
畫質越高 → 比特率越高 → 需要的頻寬與處理能力越多。
小故事 不做轉碼，就是把「挑對格式與比特率」的責任丟給使用者的裝置和網路——一旦扛不住，就是嚴重卡頓。
真實案例：前公司沒有做影片轉碼，某天有用戶反映影片特別卡，最後是 PM 事後「手動」幫他重新編碼才救回來。
本頁名詞速覽
  • 比特率（Bitrate）　每秒處理的比特數量，單位 bps
  • 編碼（Encoding）　把資料壓縮成特定格式的過程
Step 3 · 影片轉碼
13 / 31

為什麼要轉碼？容器與編碼器的差別

便當盒（容器）vs. 怎麼把菜壓進去（編碼器）

轉碼的 4 個原因
01　原始檔太大
1 小時 HD 60fps 影片可能佔用幾百 GB。
02　裝置/瀏覽器格式相容性
許多設備與瀏覽器只支援某些格式，必須轉換。
03　不同頻寬給不同畫質
高頻寬高解析、低頻寬低解析，品質與流暢度兼顧。
04　網路條件會變動
特別是行動裝置，要能自動或手動切換畫質。
容器（Container）vs 編碼器（Codec）
容器（Container）
編碼器（Codec）
作用
像一個籃子，包含影片、音訊和 metadata
壓縮與解壓演算法，減少影片尺寸同時保留品質
判斷方式
看副檔名
看影片資訊（媒體 player 顯示）
常見範例
.avi　.mov　.mp4
H.264　VP9　HEVC
本頁名詞速覽
  • 容器（Container）　影片檔案的封裝格式，裝載影片、音訊、字幕等內容
  • 編碼器（Codec）　Coder + Decoder 的縮寫，壓縮/解壓影片資料的演算法
  • H.264 / VP9 / HEVC　三種最常用的影片編碼器
Step 3 · 轉碼架構
14 / 31

為什麼要用 DAG 模型？

不同創作者有不同處理需求 → 需要可組合的抽象層

動機（書原文）
轉碼影片的計算成本很高、且很耗時。不同的內容創作者可能有不同的影片處理要求：
  • 有些創作者需要在影片上加浮水印
  • 有些自己提供縮圖
  • 有些上傳 HD 影片，有些則不需要
抽象層 · DAG 編程模型
DAG = Directed Acyclic Graph（有向無環圖）
分階段定義任務，任務之間可以序列或平行執行。無相依的任務平行跑，可縮短整體轉碼時間。
Facebook 的串流影片引擎 Streaming Video Engine（SVE） 就採用 DAG 模型（SOSP 2017）。
figure 14-8 DAG model
本頁名詞速覽
  • 有向無環圖（Directed Acyclic Graph, DAG）　節點之間有方向、但不形成迴圈的圖結構，常用來描述任務相依關係
  • SVE　Facebook 的 Streaming Video Engine，2017 年 SOSP 會議論文發表
Step 3 · 轉碼架構
15 / 31

可套用在影片上的處理任務（範例）

原始影片 → 影片 / 音訊 / metadata 三部分

01　檢查（Inspection）
確保影片有良好的品質，沒有格式損毀。
02　影片編碼（Video Encodings）
轉換以支援不同的解析度、編碼器、比特率等。圖 14-9 顯示一個影片編碼檔案的範例。
03　縮圖（Thumbnail）
可由使用者上傳，或由系統自動生成。
04　浮水印（Watermark）
在影片畫面上疊加標識資訊，用於版權識別。
figure 14-9 encoded video files
本頁名詞速覽
  • 縮圖（Thumbnail）　影片預覽用的小圖
  • 浮水印（Watermark）　疊在影片上的標識，常含品牌名或 logo
Step 3 · 轉碼架構
16 / 31

轉碼架構：六大組件

轉碼伺服器的內部結構總覽

figure 14-10 architecture overview
01
預處理器
影片切片、生成 DAG、快取
02
DAG 排程器
把 DAG 拆成各階段任務、丟到任務佇列
03
資源管理器
管理資源分配（三個佇列 + 任務排程器）
04
任務工作者
實際執行 DAG 中定義的任務
05
暫時儲存
依資料類型選不同儲存系統
06
編碼後的影片
轉碼管線的最終輸出
Step 3 · 組件 1
17 / 31

組件 1：預處理器（Preprocessor）

4 大職責：切片 · 為舊客戶端切片 · 生成 DAG · 快取

01　影片切片
影片串流會被切分為一系列對齊的影格群組（GOP）。GOP 是按特定順序排列的影片影格序列，每個切片是可獨立播放的單元，長度通常為幾秒鐘。
02　為舊客戶端切片
某些舊行動裝置或瀏覽器不支援影片分割，預處理器會以 GOP 對齊方式為這些舊客戶端切片。
03　DAG 生成
預處理器根據客戶端程式設計者編寫的配置檔生成 DAG。圖 14-12 是 2 節點 1 邊的簡化 DAG，由圖 14-13 的兩個配置檔生成。
04　快取資料
預處理器是分段影片的快取，將 GOP 與 metadata 儲存在暫時儲存中。如果影片編碼失敗，可使用持久化資料進行重試。
figure 14-11 preprocessor
figure 14-12
figure 14-13
本頁名詞速覽
  • 影格群組（Group of Pictures, GOP）　一組可獨立播放的連續影格序列，通常幾秒鐘長
  • 切片（Chunk）　影片被切分後的小段資料
Step 3 · 組件 2
18 / 31

組件 2：DAG 排程器

階段內並行 · 階段間相依

功能（書原文）
DAG 排程器把 DAG 圖分割成各階段的任務，並把它們放在資源管理器的任務佇列中。
圖 14-15 範例 · 兩階段
階段 1
影片、音訊、metadata 分離
階段 2
影片檔案 → 影片編碼 + 縮圖（兩個任務並行）；音訊檔案 → 音訊編碼
各階段間有相依關係，同一階段內的任務可以並行，前一階段完成才能進入下一階段。
figure 14-14
figure 14-15
本頁名詞速覽
  • 排程器（Scheduler）　負責決定何時、由誰執行任務的元件
Step 3 · 組件 3
19 / 31

組件 3：資源管理器

3 個佇列 + 1 個任務排程器

任務佇列
Task Queue
優先序佇列
存放要執行的任務
工作者佇列
Worker Queue
優先序佇列
含工作者利用率資訊
執行中佇列
Running Queue
含目前正在執行的任務資訊
任務排程器（Task Scheduler）
挑選最佳任務 / 工作者，並指示所選的工作者執行工作。
運作流程（書原文 5 步驟）
  • 1
    從任務佇列取得最高優先序的任務
  • 2
    從工作者佇列取得最佳工作者
  • 3
    指示所選工作者執行該任務
  • 4
    把任務/工作者資訊放入執行中佇列
  • 5
    工作完成後，從執行中佇列移除
figure 14-16
figure 14-17
本頁名詞速覽
  • 資源管理器（Resource Manager）　負責任務分配與資源調度的核心元件
  • 優先序佇列（Priority Queue）　按優先級排序的佇列資料結構
Step 3 · 組件 4~6
20 / 31

組件 4~6：工作者、暫存、輸出

三個組件合併講；轉碼架構至此完整

組件 4　任務工作者
任務工作者執行 DAG 中定義的任務。不同工作者可以執行不同任務：
  • 編碼工作者　→ 影片編碼
  • 縮圖工作者　→ 生成縮圖
  • 浮水印工作者　→ 加浮水印
figure 14-18
figure 14-19
組件 5　暫時儲存
使用多種儲存系統。選擇依據：資料類型、大小、存取頻率、資料壽命。
  • metadata（小、頻繁存取）→ 記憶體快取
  • 影片/音訊資料（大、暫存）→ BLOB 儲存
影片處理完成後，暫時儲存中的資料會被釋放。
figure 14-20
組件 6　編碼後的影片
編碼管線的最終輸出。
funny_720p.mp4
書中範例檔名，命名包含畫質與容器格式。
figure 14-21
本頁名詞速覽
  • 任務工作者（Task Workers）　實際執行轉碼任務的程序
  • 暫時儲存（Temporary Storage）　處理過程中暫存資料的儲存系統
Step 3 · 速度優化 1
21 / 31

速度優化 1：以 GOP 並行上傳

把整支影片當一個整體上傳是低效的

解法
透過 GOP 對齊，把影片分割成小塊（chunk）並行上傳：
  • 失敗時可從中斷處快速續傳，不必整支重來
  • 多個 chunk 可同時上傳，整體更快
Client 端切片（圖 14-23）
按 GOP 切分檔案的工作可以由客戶端實作，以提高上傳速度：減輕伺服器負擔、上傳前就先切好。
→ 想想下載大檔案也是分塊的，原理相同。GOP 在預處理器頁介紹過，這裡是它真正發揮作用的場景。
AI 補充 為何不直接按位元組（byte）切？影片有影格依賴，byte 會切在 GOP 中間，那塊就無法獨立解碼／轉碼。切在 GOP 邊界每塊自帶關鍵影格、自成一體，才能直接平行轉碼並複用於串流。
figure 14-22 parallel upload
figure 14-23 client chunking
Step 3 · 速度優化 2
22 / 31

速度優化 2：把上傳中心放在靠近使用者的地方

CDN 不只能往使用者方向送，也能往 CDN 方向收

在全球設立多個上傳中心
  • 美國的人　→ 北美的上傳中心
  • 中國的人　→ 亞洲的上傳中心
  • 歐洲的人　→ 歐洲的上傳中心
實作方式
使用 CDN 作為上傳中心。
CDN 不只用於下載/串流（從 CDN 往使用者方向），也可以用於上傳（從使用者往 CDN 方向）。透過全球分布的 edge server，使用者上傳時距離最短、速度最快。
figure 14-24 global upload
Step 3 · 速度優化 3
23 / 31

速度優化 3：用訊息佇列實現高並行

透過解耦把序列流程改為並行流程

BEFORE
figure 14-25
沒有訊息佇列 · 強耦合
從原始儲存系統到 CDN，每一步的輸出依賴前一步的輸入。下載 → 編碼 → 推送 CDN，每步必須等前一步完成，並行化困難。
AFTER
figure 14-26
引入訊息佇列 · 低耦合
編碼模組不需要再等待下載模組的輸出。如果訊息佇列中存在事件，編碼模組可以平行地執行這些工作。
本頁名詞速覽
  • 解耦（Decoupling）　減少元件之間的相依關係，讓它們可以獨立運作
  • 訊息佇列（Message Queue）　暫存訊息的中介系統，讓生產者與消費者解耦
Step 3 · 安全優化 1
24 / 31

安全優化 1：預簽名 URL（Pre-signed URL）

可信代理 + 短時效授權；大檔案不必穿過 API 伺服器

figure 14-27 pre-signed URL
動機
確保只有授權使用者將影片上傳到正確的位置。
3 步驟流程
  • 1
    客戶端向 API 伺服器發出 HTTP 請求，要求取得預簽名 URL。這個 URL 包含對特定物件的存取許可。
  • 2
    API 伺服器以預簽名 URL 回應。
  • 3
    客戶端收到回應後，使用這個預簽名 URL 上傳影片。
AWS S3
Pre-signed URL
Azure Blob Storage
Shared Access Signature（SAS）
本頁名詞速覽
  • 預簽名 URL（Pre-signed URL）　包含臨時授權資訊的 URL，可在指定時間內存取特定資源
Step 3 · 安全優化 2
25 / 31

安全優化 2：保護你的影片

三種版權保護方案（可同時使用，不互斥）

「許多內容創作者不願意在網上發布影片，因為擔心自己的原創影片會被盜。為了保護有版權的影片，可以採取以下三種方案之一。」
方案 1

數位版權管理（DRM）

三大主流 DRM 系統
  • Apple FairPlay　Apple 生態系
  • Google Widevine　Chrome、Android
  • Microsoft PlayReady　Xbox、Windows
方案 2

AES 加密

高階加密標準
  • 加密影片並配置授權策略
  • 加密的影片在播放時被解密
  • 只有授權使用者才能觀看
方案 3

影片浮水印

疊加識別資訊
  • 在影片上疊加識別資訊的圖像
  • 可以是公司 logo 或公司名稱
  • 主要用於識別內容來源、嚇阻盜版
小故事 DRM 防得了螢幕截圖，卻防不了「類比漏洞」——拿另一支手機對著螢幕拍。
真實案例：學員反映 DRM 影片截不了圖，我們的建議是……直接用拍的。
類比漏洞 meme：用手機拍螢幕
本頁名詞速覽
  • 數位版權管理（Digital Rights Management, DRM）　管理數位內容存取權限的技術
  • 高階加密標準（Advanced Encryption Standard, AES）　對稱式加密演算法標準
Step 3 · 安全優化 3 書外補充
26 / 31

安全優化 3：播放存取保護

上傳用 Pre-signed URL；那「播放」怎麼擋盜連？→ CDN 的 Signed URL / Signed Cookie

從「上傳」延伸到「播放」
#24 確保只有授權者能上傳；影片放上 CDN 後，同樣要確保只有授權者能播放／下載。CDN 提供兩種存取控制：
Signed URL
Signed Cookie
簽章對象
單一檔案網址
一個 cookie 涵蓋整個路徑下多個檔案
網址
每個檔案網址都不同（會變）
網址不變
適用
單一檔案、客戶端不支援 cookie
多分段影片、長時間播放
為什麼影片偏好 Signed Cookie？關鍵在「換發時會不會中斷播放」
影片 = 1 份 manifest（目錄）+ 數百個分段，而分段網址就寫在 manifest 裡。
  • Signed URL：簽章在網址裡 → 換發常要重載 manifest，播放被迫暫停、記住進度再 seek 回來（除非用播放器 request filter 每請求動態補簽）。
  • Signed Cookie：簽章在 cookie → 背景刷新即可，manifest 不動、播放無感不中斷。
它跟 #25 的 DRM 重複嗎？→ 不，是不同層
存取層（Signed URL／Cookie）：擋「沒授權的人來抓檔」。
內容層（AES／DRM）：檔案被抓走也播不了。
兩者互補、可並存——cookie 當門禁、DRM 鎖內容。
本頁名詞速覽
  • Manifest（播放清單）　影片的「目錄」檔（HLS 的 .m3u8／DASH 的 .mpd），列出各畫質版本與每個分段的網址、順序
  • Signed URL　帶簽章與時效的單一檔案網址，用來授權存取「一個」檔案
  • Signed Cookie　帶簽章與時效的 cookie，一次授權「整個路徑下多個檔案」，且網址不變
Step 3 · 成本優化
27 / 31

成本優化：長尾分布的啟示

少數熱門影片被頻繁存取，其他多數沒人看

figure 14-28 long tail
核心觀察
YouTube 影片串流遵循長尾分布（Long-tail Distribution）：
  • 少數熱門影片被頻繁存取
  • 其他許多影片的觀眾很少或沒有
策略 1　CDN 只服務熱門影片
其他影片由高容量儲存的影片伺服器服務。
少數熱門影片放 CDN，絕大多數冷門影片由內部儲存伺服器直接服務。
策略 2　冷門影片按需編碼
不太受歡迎的內容不需要儲存許多編碼版本。短影片可以按需編碼。
  • 主流畫質先存好
  • 較不常用的畫質（240p、1440p）等到有人請求時再現場編碼
本頁名詞速覽
  • 長尾分布（Long-tail Distribution）　少數項目佔據大量需求、其餘大量項目分散需求的統計分布
  • 按需編碼（On-demand Encoding）　使用者請求時才現場進行的編碼
Step 3 · 成本優化
28 / 31

成本優化：策略 3 與策略 4

地區性分發 · 與 ISP 合作

策略 3　地區性影片不全球分發
「有些影片只在某些地區流行。沒有必要將這些影片分發到其他地區。」
  • 一支日本動漫剪輯主要觀眾在亞洲　→ 不必分發到南美 CDN 節點
  • 一個西班牙語西甲球賽片段　→ 不必分發到亞洲 CDN
策略 4　自建 CDN + 與 ISP 合作
「像 Netflix 那樣建立你自己的 CDN，並與網際網路服務供應商（ISP）合作。建立自己的 CDN 是一個巨大的項目；然而，這對大型串流公司來說可能是有意義的。」
Netflix Open Connect 方案
  • ISP 例子：Comcast、AT&T、Verizon
  • ISP 分布在世界各地，離使用者很近
與 ISP 合作好處
  • 改善觀看體驗（更短的網路路徑）
  • 減少頻寬費用
書中收尾提醒　所有優化都基於內容流行度、使用者存取模式、影片大小等。在做任何優化之前，分析歷史觀看模式是很重要的。
本頁名詞速覽
  • 網際網路服務供應商（Internet Service Provider, ISP）　提供網路接入服務的公司，如 Comcast、AT&T
  • Open Connect　Netflix 自建的 CDN 計畫，把伺服器放到 ISP 機房裡
Step 3 · 錯誤處理
29 / 31

錯誤處理：可恢復 vs 不可恢復

分類錯了，會浪費資源在不可能成功的重試

「對於大規模系統，系統錯誤是不可避免的。為了建立一個高度容錯的系統，必須優雅地處理錯誤並快速恢復。」
RECOVERABLE

可恢復錯誤

範例：影片段轉碼失敗
一般處理思路
  • 重試幾次操作
  • 如果任務持續失敗、系統認為無法恢復，回傳適當的錯誤碼給客戶端
NON-RECOVERABLE

不可恢復錯誤

範例：影片格式損毀（畸形的影片格式）
處理思路
  • 停止與該影片相關的所有任務
  • 回傳適當的錯誤碼給客戶端
  • 不重試（重試也沒用）
本頁名詞速覽
  • 容錯（Fault-tolerant）　系統在部分元件失效時仍能正常運作的能力
Step 3 · 錯誤處理
30 / 31

各組件的錯誤處理策略

設計時就要為錯誤鋪好路

組件 / 錯誤類型處理策略分類
上傳錯誤重試幾次任務型 · 可重試
影片切片錯誤舊版客戶端無法 GOP 切片 → 整支傳給伺服器端切片任務型 · 可重試
轉碼錯誤重試任務型 · 可重試
預處理器錯誤重新生成 DAG 圖任務型 · 可重試
DAG 排程器錯誤重新排程任務任務型 · 可重試
資源管理器佇列當機使用副本有狀態 · 副本
任務工作者故障在新工作者上重試任務任務型 · 可重試
API 伺服器故障API 伺服器無狀態，請求導向其他伺服器無狀態 · 自動
元資料快取當機多份副本，從其他節點取得；起新伺服器取代有狀態 · 副本
元資料 DB 主節點當機將從節點（Slave）提升為主節點有狀態 · 副本
元資料 DB 從節點當機從另一個從節點讀取；起新伺服器取代有狀態 · 副本
設計關鍵 ①
無狀態服務　容易處理
設計關鍵 ②
有狀態資料　需要副本
設計關鍵 ③
任務型錯誤　可以重試
本頁名詞速覽
  • 無狀態（Stateless）　服務本身不儲存任何狀態，每個請求都是獨立的
  • 主從架構（Master-Slave）　一個主節點負責寫入、多個從節點負責讀取的資料庫架構
  • 副本（Replica）　資料的複本，用於高可用與讀取擴展
Step 4 · 總結
31 / 31

Step 4 · 總結與補充要點

面試結束前還有時間？可以聊這些

擴展 API 層
API 伺服器是無狀態的，因此很容易水平擴展。
擴展資料庫
可以談資料庫複製（Replication）與分片（Sharding）策略。
現場直播（Live Streaming）
直播和點播有相似之處（上傳、編碼、串流），但有顯著差異：
  • 直播有更高的延遲要求，可能需要不同的串流協定
  • 直播對並行性要求較低，因為小塊資料已被即時處理
  • 直播需要不同的錯誤處理機制——任何耗時太長的處理都不可接受
影片下架（Video Takedowns）
侵犯版權、色情等違規影片需要被下架。有些可在上傳過程中被系統偵測，有些則透過使用者檢舉發現。
本頁名詞速覽
  • 水平擴展（Horizontal Scaling）　增加更多機器來分散負載，而非升級單一機器
  • 現場直播（Live Streaming）　影片即時錄製並同步播送給觀眾的傳輸方式