上周在等電梯時，發現在 4G 網絡或者無網絡的情況下，抖音、B 站的視頻依舊可以正常觀看，在視頻發布時，甚至可以做到無網卡頓 ——> 連網續傳的無縫連接操作。

于是，又想起了曾經在某視頻平臺的面試經歷。

引言

面試官：“在抖音、快手這類億級日活平臺，用戶輕點 發布 的背后，藏著視頻上傳與轉碼的 生死時速 —— 這倆看似簡單的 傳文件、改格式 操作，直接決定了用戶是 秒發秒看 還是 怒刪 APP。

聽說你對視頻傳輸和轉碼有一定研究，那簡單說下短視頻的上傳轉碼流程吧！”

今天小?就帶著零星的面試記憶，帶著大家扒一扒短視頻上傳轉碼的全流程：從時序圖理清組件協作，到拆解決策邏輯、優化技巧，手把手帶你體驗一套又穩又快的視頻生產鏈路。

一、視頻上傳與轉碼整體時序圖

便于大家理解，我畫了個時序圖。要理解整個流程，首先得看清各組件之間的協作關系。

以下時序圖覆蓋了從 “客戶端發起上傳” 到 “轉碼完成入庫” 的全鏈路，涉及客戶端、API 網關、上傳服務等 7 類核心組件，每一步都標注了關鍵技術選型和數據流向，讓你一目了然。

圖片

可惜當時是線上面試，時序圖顯然來不及準備了，于是我口述了下面的內容。

1. 客戶端發起上傳請求，獲取分片上傳憑證（對應時序圖 1-6 步）

圖片

1.1 涉及模塊及作用

• Client（客戶端）：用戶操作的入口（如抖音 APP），核心作用是收集視頻元數據（大小、格式、整體 MD5），并向網關發起 “申請分片上傳” 的請求 —— 這一步是為了避免直接上傳大文件時的風險，先拿到 “上傳許可”。
• APIGW（API 網關）：系統的 “入口守衛”，作用是統一接收客戶端請求，先做兩件關鍵事：①鑒權（驗證用戶 Token 是否有效，防止非法上傳）；②限流（比如限制單個用戶每秒最多發起 2 次上傳請求，避免惡意刷量），之后再將請求轉發給上傳服務。
• UploadSvc（上傳服務）：上傳流程的 “協調者”，不直接存儲視頻，而是負責與對象存儲交互，申請 “分片上傳憑證（UploadId）”——UploadId 是對象存儲分配的唯一標識，用于后續分片上傳、合并的身份驗證，避免不同用戶的分片混淆。
• OSS（對象存儲）：視頻分片的 “臨時倉庫”，作用是生成并返回 UploadId 和分片編號范圍（比如 1-10 片，對應 10MB 視頻按 1MB 拆分），同時提供后續分片上傳的接口地址。

1.2 交互邏輯與設計原因

這時，面試官針對細節發問了：“為什么客戶端不直接調用 OSS，而是要通過 API 網關和上傳服務？”

我心想，這不是小 case 嘛：“如果客戶端直接對接 OSS，會暴露 OSS 的訪問密鑰，存在數據泄露風險。

通過網關和上傳服務中轉，既能統一鑒權、限流，又能隱藏后端存儲細節，后續切換存儲服務商（如從阿里云 OSS 換成騰訊云 COS）時，客戶端無需修改代碼?！?/p>

“那為什么要先申請 UploadId 呢？”

“分片上傳是 分多次傳碎片，UploadId 相當于碎片的歸屬標識—— 只有攜帶正確 UploadId 的分片，OSS 才會認為是同一視頻的碎片，后續才能合并成完整文件，避免不同視頻的分片混在一起。”

這時，面試官微微點了點頭，“好，你接著往下說?！?/p>

2. 客戶端分片上傳視頻數據（對應時序圖 7-8 步，循環執行）

圖片

2.1 涉及模塊及作用

• Client（客戶端）：按 1MB / 片拆分視頻，并發發起分片上傳請求（每次傳 1 個分片，攜帶 UploadId、分片號、分片數據）—— 并發上傳是為了提速，比如同時傳 3 個分片，比一個一個傳快 2-3 倍。
• OSS（對象存儲）：接收并存儲單個分片，校驗分片的完整性（比如通過分片 MD5），之后返回 “ETag 值”——ETag 是分片的唯一標識，相當于 “碎片的簽收單”，客戶端后續需要用 ETag 證明 “這個分片已傳成功”。

這時，面試官又問了：“這個 ETag 有啥作用呢？”

我心想，就猜到你會這么問：當然是為了 數據一致性校驗了，客戶端后續通知 “上傳完成” 時，會把所有分片的 ETag 列表傳給上傳服務，上傳服務再拿給 OSS——OSS 會對比自己存儲的分片 ETag 和客戶端上報的 ETag，只有全部一致，才會執行合并，避免分片丟失或損壞。

3. 客戶端完成上傳，觸發分片合并（對應時序圖 9-15 步）

圖片

當我說完上面的流程時，面試官心想，有點意思，不過面上也不能表現出來。于是繼續發問：“為什么要通過 Kafka 發轉碼任務，而不是上傳服務直接調用轉碼服務？”

“這個是很常見的消息中間件的作用，就是避免 服務耦合 和 單點故障：如果上傳服務直接調用轉碼服務，轉碼服務宕機時，上傳服務會被阻塞，甚至拖垮。”

用 Kafka 做中間件，上傳服務發完消息就 “解脫”，轉碼服務恢復后可以繼續消費任務，不會丟失；同時，后續增加多個轉碼節點時，只需讓它們共同消費 Kafka 的任務，就能實現負載均衡。

4. 轉碼服務消費任務，處理多碼率轉碼（對應時序圖 16-20 步）

圖片

4.1 涉及模塊及作用

• TranscodeSvc（轉碼服務）：從 Kafka 中消費轉碼任務（按優先級拉取，熱門用戶任務優先），先通過 OSS SDK 讀取視頻源文件，再調用 FFmpeg 工具進行多碼率轉碼 —— 轉碼的核心是 “適配不同網絡環境”，比如 480P 給弱網用戶，1080P 給 5G 用戶。

講到這里，面試官才微微點頭，看來是有實踐過的。于是問了一個影響實際體驗的問題：

4.2 為什么要按優先級拉取任務？

這個問題很簡單，無非就是系統中場景的熱 key 問題。

關鍵在于保障 “核心用戶體驗”：熱門用戶（如粉絲 10 萬 + 的創作者）的視頻上線速度很重要，若和普通用戶的任務一起排隊，可能會延遲很久，影響創作者積極性。按優先級排序后，熱門用戶的任務先處理，普通用戶的任務后續處理，平衡 “核心需求” 和 “普通需求”。

4.3 那為什么要同時轉 480P/720P/1080P 多碼率呢？

主要是適配 “多樣化網絡與設備”：用戶的網絡環境差異大（2G/3G/4G/5G/WiFi），設備屏幕分辨率也不同（手機 / 平板 / 電腦）—— 弱網用戶用 480P，播放不卡頓；高速網絡用戶用 1080P，體驗高清；多碼率并存，能讓不同場景的用戶都有好體驗。

5. 轉碼完成，寫入 CDN 源站，更新元數據（對應時序圖 21-25 步）

圖片

5.1 涉及模塊及作用

• CDNSource（CDN 源站）：存儲轉碼后的視頻文件，后續會同步到全國的 CDN 節點（如北京、上海、廣州的節點）—— 用戶播放視頻時，會從就近的 CDN 節點拉取，減少延遲（比如廣州用戶從廣州節點拉取，比從北京源站拉取快 1-2 秒）。
• Kafka（消息隊列）：接收上傳服務發送的 “審核任務消息”—— 視頻上線前必須審核（防止違規內容），通過 Kafka 轉發審核任務，讓審核服務異步處理，不阻塞上傳服務的后續操作。

5.2 為什么要把視頻放到 CDN，而不是直接從 OSS 播放？

降低 “源站壓力” 和 “用戶延遲”：如果所有用戶都從 OSS 拉取視頻，OSS 的帶寬壓力會極大，且跨地域訪問延遲高（如新疆用戶訪問北京 OSS，延遲可能 100ms+）；CDN 有全國節點，用戶就近訪問，延遲低（通常 20-50ms），且 CDN 能緩存熱門視頻，減少對 OSS 的請求，降低整體成本。

講到這里，我感覺面試官還沒想好接下來的問題，于是又補充了一下，做個小小的總結。

6. 整個流程背后的核心設計思想

上述整個時序圖的交互邏輯，圍繞三個核心目標展開：

• 可靠性：通過分片上傳、ETag 校驗、任務重試，確保視頻數據不丟失、不損壞；
• 效率性：通過并發上傳、GPU 轉碼、CDN 分發，讓視頻上傳快、轉碼快、播放快；
• 可擴展性：通過 API 網關、消息隊列、微服務拆分（上傳 / 轉碼 / 審核獨立），后續增加節點、切換組件（如換 OSS、換 CDN）時，系統能靈活應對，支撐業務增長（從百萬級用戶到億級用戶）。

理解這些模塊作用和交互邏輯，就能掌握短視頻上傳與轉碼的核心設計思路，后續遇到類似場景（如大文件上傳、音視頻處理），也能復用這些技術方案。

二、關鍵技術細節拆解

這時，面試官調整了下坐姿，說：“嗯，那你再說說分片上傳的設計吧”。

看到這里，想必大家和面試官一樣，都已經了解了視頻上傳的大概。于是我們再深入每個環節的技術核心，解決實際開發中可能遇到的 “坑”。

1. 分片上傳的核心設計：解決 “大文件上傳失敗” 問題

短視頻文件通常在 10-50MB 之間，若采用 “一次性上傳”，一旦遇到網絡波動，就可能導致全量重傳，用戶體驗極差。

分片上傳通過三大設計，從根本上解決這一問題：

1.1 分片大小選擇

我們采用 1MB / 片的規格，這是兼顧并發效率與對象存儲接口限制的最優解。

以阿里云 OSS 為例，單分片最大支持 5GB，但小分片更易重試 —— 哪怕某一個 1MB 的分片上傳失敗，重新上傳也只需幾秒，而非整個幾十 MB 的視頻。

1.2 斷點續傳

客戶端會記錄每一個已成功上傳分片的 ETag（對象存儲返回的唯一標識），下次上傳同一視頻時，只需對比本地分片 MD5 與 OSS 中的 ETag，僅重新上傳未成功的分片。

比如用戶上傳到一半退出 APP，再次打開時，系統能自動續傳剩余分片，無需從頭開始。

1.3 數據一致性校驗

兩層校驗保障文件完整：

一是客戶端上傳前計算視頻整體 MD5，與服務端預存的 MD5 比對，避免文件損壞后無效上傳。

二是分片合并時，OSS 會自動校驗所有分片的 ETag 是否與客戶端上報的一致，只要有一個分片不匹配，就拒絕合并，防止最終視頻文件損壞。

這時，面試官又點了點頭，問到了系統中的高可用問題：“假設我們需要開發高并發、海量用戶的短視頻系統，你會從哪些方面考慮呢？”

2. 轉碼服務的架構設計：兼顧效率與資源成本

轉碼是典型的 CPU 密集型操作，在高峰期，每秒可能有上萬條轉碼任務涌入，若架構設計不合理，要么轉碼慢到用戶等不及，要么資源消耗過高導致成本飆升。

我們通過 “集群化 + 異步化” 的設計，平衡效率與成本。

2.1 任務調度策略

采用 “優先級隊列” 機制，根據用戶等級和視頻熱度分配資源。熱門用戶（粉絲數 > 10 萬）的視頻轉碼任務設為 “高優先級”，確保其內容快速上線。

普通用戶任務設為 “中優先級”；歸檔視頻（超過 3 個月無播放）設為 “低優先級”，錯峰處理。

同時，轉碼服務通過 Kafka 分區實現任務分片，每個轉碼節點只消費指定分區的任務，避免重復處理和資源爭搶。

2.2 轉碼參數優化

編碼格式和碼率是影響視頻質量與存儲成本的關鍵。

我們選擇 H.265（HEVC）編碼，相比常用的 H.264，能節省 30% 的存儲空間，且支持移動端硬解碼，播放更流暢。碼率則分為三檔：480P（800kbps）適配 2G/3G 弱網環境，720P（1.5Mbps）應對主流 WiFi，1080P（3Mbps）滿足 5G / 高速 WiFi 下的高清需求，客戶端會根據用戶當前網速自動切換。

2.3 資源隔離

為避免不同業務爭搶資源，我們將轉碼集群按業務線拆分，直播轉碼和短視頻轉碼使用獨立集群 —— 比如直播高峰期（晚上 8-10 點），不會占用短視頻轉碼的 CPU 資源。

同時，通過 Linux cgroups 限制單個轉碼任務的最大 CPU 使用率（不超過 20%），防止單個大視頻轉碼拖垮整個節點。

3. 異常處理機制：保障流程穩定性

在高并發場景下，異常是常態，一套完善的異常處理機制，能讓系統在故障時 “不崩、不丟數據”：

• 上傳失敗重試：分片上傳超時（如 5 秒無響應）時，客戶端會自動重試 3 次，且每次重試間隔指數遞增（1 秒→2 秒→4 秒），減少網絡波動的影響。若 3 次重試仍失敗，上傳服務會將該視頻標記為 “上傳異?！保⒂|發定時任務（每 10 分鐘）重新發起分片合并，避免用戶手動重試的麻煩。
• 轉碼失敗降級：若某一碼率轉碼失敗（比如 1080P 轉碼報錯），轉碼服務不會中斷整個任務，而是跳過該碼率，優先保證 480P 和 720P 可用，同時記錄失敗日志并觸發人工排查。對于轉碼超時的任務（如 30 分鐘未完成，通常是超大文件），會自動終止并降級為 “低優先級”，待資源空閑時重新處理，不占用實時任務的資源。
• 數據一致性保障：上傳服務與轉碼服務通過 “視頻 ID” 唯一關聯，轉碼完成后，必須更新 MySQL 中該視頻的 “轉碼狀態”。若超過 5 分鐘未更新，定時任務會重新發送轉碼任務，防止數據丟失。此外，若 OSS 分片合并失敗，上傳服務會自動刪除已上傳的分片，避免存儲垃圾數據，同時通知客戶端重新上傳。

講到這里，面試官已經正襟危坐，透過電腦屏幕我看到他又開始打量起了我的簡歷，但這時我仿佛面試之神附身，意猶未盡，于是接著發揮。

三、性能優化實踐

光穩定還不夠，還要 “快”—— 用戶上傳快、視頻轉碼快、播放加載快，這需要針對性的性能優化。

3.1 客戶端上傳速度優化

• 并發分片上傳：客戶端同時發起 3-5 個分片上傳請求（根據網絡環境動態調整，弱網時降為 1-2 個），相比串行上傳，速度能提升 2-3 倍。比如一個 10MB 的視頻，拆分為 10 個 1MB 分片，并發上傳只需 2-3 秒，而串行上傳可能需要 5-6 秒。
• QUIC 協議替代 HTTP/2：在弱網環境（如地鐵、偏遠地區），HTTP/2 的 TCP 連接容易丟包重傳，我們改用 QUIC 協議（基于 UDP），支持 0-RTT 連接建立，上傳成功率能提升 15% 以上（實測數據）。比如在地鐵中，HTTP/2 上傳成功率約 70%，QUIC 能提升到 85% 以上。
• 預上傳校驗：客戶端上傳前先校驗視頻格式（僅支持 MP4/AVI/MOV），不符合格式的直接提示用戶，避免無效上傳。同時提前計算分片 MD5，若發現分片損壞，直接丟棄并重新分片，減少上傳后校驗失敗的概率。

3.2 轉碼效率優化

• GPU 加速轉碼：對熱門視頻（日播放量 > 10 萬），我們采用 NVIDIA Tesla T4 GPU 進行轉碼，相比傳統 CPU（Intel Xeon 8375C），速度快 4-5 倍。比如一個 5 分鐘的視頻，CPU 轉碼需要 10 秒，GPU 轉碼只需 2 秒，大幅縮短視頻上線時間。
• 轉碼任務批量處理：當同一創作者發布多個視頻時，我們會將這些視頻的轉碼任務合并，復用一次 OSS 連接和 FFmpeg 初始化資源，減少 IO 開銷。比如某創作者一次發布 3 個視頻，批量處理比單獨處理能節省 30% 的時間。
• 熱點視頻預轉碼：通過用戶行為預測提前觸發轉碼。比如某創作者歷史視頻播放量均破萬，當其剛發布新視頻時，系統會預判該視頻會成為熱點，提前啟動轉碼，避免用戶等待 —— 原本需要等轉碼完成才能觀看，現在發布后 1-2 秒就能加載播放。

講到這里，面試官趕緊示意我停止，說：“嗯 小伙子還不錯，短視頻這塊的上傳轉碼看來有專門了解過，好了，今天的面試先到這里吧，你有什么想問的嗎？”

于是我問了幾個不痛不癢的專業問題后，結束了這次面試。

小結

視頻上傳與轉碼作為短視頻系統的 “內容入口”，是技術落地的關鍵一環。從分片上傳解決大文件傳輸問題，到轉碼服務平衡效率與成本，再到異常處理和性能優化保障體驗，每一步都需要結合業務場景做精細化設計。

對于后臺開發者而言，理解這套流程不僅能應對 “搭建短視頻系統” 的需求，更能將其中的技術思路（如分片傳輸、異步調度、資源隔離）遷移到其他大文件處理場景（如直播、云存儲）。

當然，這只是短視頻系統的冰山一角，后續我們還會拆解視頻推薦、用戶互動等核心模塊。