前言
隨著短影音爆發，TikTok、Instagram Reels 和 YouTube Shorts 已成為現代人日常娛樂的核心。
但要支撐全球上億用戶「滑到停不下來」，同時維持隨點隨播的流暢體驗，背後涉及上傳穩定性、轉檔吞吐量、傳輸成本與推薦精準度等一整套系統設計。
本篇文章以「一億活躍用戶」為背景，透過五維度分析法，拆解 Video Sharing Platform 的底層架構與技術權衡。
這篇你可以帶走什麼
- 短影音平台最核心的資料流與容量壓力
- 上傳流程與觀看流程為何必須分開優化
- 為什麼 Blob Storage + NoSQL 往往比傳統 RDBMS + HDFS 更務實
- 推薦系統如何從追蹤流演進到演算法流
維度一、可直接觀察的事實：系統邊界與流量特徵
短影音平台的本質資料流只有兩件事：
- Inflow：創作者上傳影片
- Outflow：一般用戶觀看影片
這是典型的讀多寫少（Read-heavy）系統。假設有 1 億 DAU：
- 每人每天看 100 支影片
- 可能不到 1% 的人會上傳 1 支影片
再看資料規模。若短影音平均 1 分鐘、壓縮後約 10MB，且每天 100 萬支上傳：
- 每日新增資料約 10TB
此外，影片由連續 Frames 組成，不是單一靜態檔案，因此在時間與空間維度都具備高可壓縮性，這會直接影響編碼與傳輸策略。
重點：短影音系統的主戰場不是寫入 QPS，而是讀取頻寬、轉檔吞吐量與內容傳遞成本。
維度二、條件檢查：上傳與觀看的最佳解
上傳最佳解（Segmented Upload + Async Processing）
手機網路（Wi-Fi / 行動數據）不穩定是常態，因此上傳流程應採：
- 客戶端切片（Segment）
- 並行上傳（Parallel Upload）
- 斷點續傳（Resume）
上傳完成後，不應同步轉檔，而是透過 Message Queue（如 Kafka）觸發後端 Worker Pool 做非同步轉檔，生成 1080p、720p、480p 等多畫質版本。
觀看最佳解（CDN + HLS）
為降低跨區延遲與首播等待，需導入：
- CDN 邊緣節點快取
- 串流協定（如 HLS），先下載前幾秒切片即可播放
邊界條件（CDN 成本失控）
若把所有影片無差別塞進 CDN，流量費會急遽上升。常見解法是加一個 Extractor Service（熱門萃取服務）：
- 週期掃描 Blob Storage（如 S3）
- 只把點閱率飆升的熱門影片推送到 CDN
- 冷門影片維持回源讀取（直接向源站請求）
重點：CDN 是效能利器，也是成本炸彈，必須搭配熱度分層。
維度三、反證檢查：跳脫直覺的儲存架構盲點
常見直覺是：影片檔存進分散式檔案系統 (如 HDFS)，Metadata 存 MySQL等關聯式資料庫。
但在短影音場景，這組合通常不是最佳平衡。
更務實做法是：
- Blob Storage（S3 類）存實體影片
- NoSQL（Cassandra / DynamoDB）存影片 Metadata
原因在於：
- Blob Storage 對海量影音檔案的成本與擴展彈性更好
- NoSQL 具天然水平擴展能力，較能承受億級用戶下的 Metadata 存取壓力
- 可減少 MySQL 在超大規模下「資料庫分片 (Sharding)」帶來的長期維運複雜度
維度四、不確定性分析：推薦演算法的介入
先區分事實與推論。
- 觀察事實：最基礎的 News Feed 可依 Follow 關係做時間倒序
- 經驗推論：TikTok 型產品的核心成功更多來自推薦系統，而非社交追蹤
核心假設是：用戶自己也未必知道下一支想看什麼。
因此架構後期需導入 ML 團隊與雙塔模型（Two-Tower Model）：
- User Profile 轉成 User Embeddings
- Video Features 轉成 Video Embeddings
- 在用戶滑動瞬間計算 Cosine Similarity，完成候選集篩選 (Recall) 與排序 (Ranking)
維度五、最終結論與行動建議
實務上的微服務藍圖：
- Upload Service：接收切片、觸發非同步轉檔、寫入 Blob Storage
- View Service：驗證權限、派發串流 URL、配合 CDN 交付內容
- Storage Layer：NoSQL 存 Metadata，Blob Storage 存影片，CDN 快取熱門內容
破關路線圖（信心度 95%）
- 先把上傳與轉檔做成非同步解耦，穩定寫入端
- 觀看流程優先導入 CDN + HLS，優化首播體驗
- 儲存層採 Blob + NoSQL 分工，降低擴展與維運壓力
- 建立熱門萃取機制，控制 CDN 成本
- 在流量穩定後導入雙塔推薦，提升留存率與觀看時長
這套方向符合 Netflix、YouTube、TikTok 等現代影音平台的底層設計邏輯。
脆弱點提示
若平台未來從短影音轉向高互動電競直播（Live Streaming），現有依賴 HLS + CDN 的設計會遇到瓶頸。
關鍵問題是 HLS 天生約 3 到 10 秒延遲，對即時互動（抖內、抽獎、聊天室即時事件）通常不可接受。
此時需重構傳輸層，改用更低延遲協定（如 WebRTC 或 RTMP）。
一句話總結
短影音平台的關鍵不是「能播影片」而已，而是把上傳、轉檔、傳輸、儲存與推薦做成可獨立擴展的管線 (Pipeline)，才能在億級流量下同時守住體驗與成本。