引言

不知道各位后臺開發者有沒有過這樣的經歷：在地鐵上刷著抖音停不下來，回家后又在快手上看各類生活分享。

可當產品經理拍著你的肩膀說 “咱們也搞個短視頻系統” 時，瞬間從 “用戶” 切換到 “開發者” 視角，滿腦子都是 海量視頻存儲怎么搞、高并發推流怎么扛、實時推薦怎么做到精準 的靈魂拷問。

在當下的互聯網生態中，短視頻早已成為用戶時長占比最高的應用形態之一。

某音、某手等頭部平臺單日活躍用戶數以億計，每秒都有上萬條視頻被 上傳、轉碼、分發，同時還有億級用戶在實時 刷新、觀看、互動。

要支撐這樣龐大的業務規模，背后的系統架構設計絕非簡單的 “CRUD + 文件存儲” 就能搞定。

本文將以某音、某手為參考原型，從后臺技術視角拆解短視頻系統的架構設計，涵蓋整體架構分層、核心功能技術實現、關鍵技術難點突破等內容，為各位開發者提供一套可落地的短視頻系統架構思路，讓你面對 “搞個短視頻系統” 的需求時，能從容給出技術方案。

一、整體架構

短視頻系統是典型的 “高并發、海量數據、低延遲” 綜合系統，需兼顧 視頻生產（上傳、轉碼）、內容分發（推薦、CDN）、用戶互動（點贊、評論、分享） 三大核心鏈路，整體采用 “分層解耦 + 微服務化” 架構設計，從下到上可分為基礎組件層、核心服務層、算法引擎層、接入層四層，同時配套監控運維體系保障系統穩定性。

1.1 架構圖

圖片

1.2 關鍵組件說明

（1）接入層

• API 網關：采用 Kong/APISIX，負責請求路由、鑒權（JWT/OAuth2.0）、限流（令牌桶算法）、灰度發布（基于 用戶 ID / 地域 的流量切分），同時統一處理跨域、請求參數校驗，屏蔽后端服務復雜性。
• 負載均衡：使用 Nginx/LVS，結合 DNS 輪詢實現 地域級流量分發，將用戶請求引導至就近的機房節點，降低網絡延遲（如北京用戶接入北京機房，廣州用戶接入廣州機房）。
• 灰度發布：在關鍵功能上線時，特別是一些商業化能力，需要通過用戶反饋、數據看板來查看當前功能的實踐性，所以在發布時，我們會在網關層配置 用戶灰度 比例（如采用 Hash 桶散列分布的方式），讓一部分用戶首先體驗到新功能。

（2）核心服務層

• 視頻生產服務：負責視頻 上傳、轉碼、審核 流程，拆分為上傳服務（接收客戶端視頻分片）、轉碼服務（調用轉碼集群處理多碼率）、審核服務（對接內容審核接口）三個微服務。
• 視頻分發服務：核心是 “推流 - 拉流” 鏈路，包含 推流 服務（接收轉碼后的視頻流，寫入 CDN 源站）、拉流 服務（為客戶端提供視頻播放地址，支持斷點續傳）、緩存 服務（Redis 緩存熱門視頻元數據，減少 DB 訪問）。
• 互動服務：處理點贊、評論、分享、關注等互動行為，拆分為互動服務（處理點贊 / 評論的增刪改查）、關系服務（管理用戶關注 / 粉絲關系）、消息服務（推送評論通知 / 關注通知），本文主要關注核心模塊的互動服務。
• 用戶服務：管理用戶基礎信息（賬號、昵稱、頭像）、登錄態（Session/Token 管理）、權益（會員特權、創作激勵），數據存儲采用 MySQL 分庫分表（按用戶 ID 哈希分片）。

（3）算法引擎層

• 推薦模塊：核心是 “實時推薦 + 離線推薦” 雙引擎，離線推薦基于 Spark/Flink 計算用戶長期興趣（T+1 更新），實時推薦基于 Flink 流處理計算用戶短期興趣（秒級更新），最終通過推薦 API 返回個性化視頻列表。
• 用戶畫像模塊：基于用戶基礎信息、互動行為（點贊 / 評論 / 完播率）、觀看時長等數據，通過 ES（Elasticsearch）存儲用戶標簽（如 “喜歡美食”“關注汽車”），為推薦、內容審核提供數據支撐。
• 內容審核模塊：結合 AI 審核（識別違規畫面 / 文字）和人工審核，對上傳的視頻進行實時過濾，違規視頻直接攔截，疑似違規視頻進入人工審核隊列，保障內容合規性。

（4）基礎組件層

• 存儲組件：視頻文件存儲采用 對象存儲（S3/OSS），支持海量文件存儲和高并發訪問；結構化數據 （用戶信息、互動記錄）存儲采用 MySQL（主從架構），非結構化數據 （用戶畫像、日志）存儲采用 ES/HDFS；緩存 采用 Redis（集群模式，分片 + 哨兵），緩存熱門視頻元數據和用戶登錄態。
• 計算組件：離線計算 采用 Spark（處理用戶畫像、推薦模型訓練），實時計算 采用 Flink（處理實時推薦、用戶行為日志），為算法引擎提供算力支撐。
• 消息隊列：采用 Kafka（集群模式），解耦 服務間依賴，如視頻上傳完成后發送 “轉碼任務” 消息，轉碼完成后發送 “審核任務” 消息，避免服務直接調用導致的耦合。
• CDN：對接阿里云 / 騰訊云 CDN，將轉碼后的視頻緩存到全國節點，用戶拉取視頻時從就近 CDN 節點獲取，降低源站壓力，提升播放速度。

二、核心功能技術實現

圖片

2.1 視頻上傳與轉碼

• 上傳流程：客戶端采用 “分片上傳”（將視頻分成 1MB / 片），通過 HTTP/2 協議上傳至上傳服務，上傳服務校驗分片完整性后，調用對象存儲合并分片，生成視頻源文件；同時發送 “轉碼任務” 到 Kafka，轉碼服務消費消息后，調用 FFmpeg 轉碼集群，將源視頻轉成 480P/720P/1080P 多碼率格式，轉碼完成后更新視頻元數據狀態。
• 關鍵技術：分片上傳（斷點續傳，避免網絡中斷重傳整個視頻）、異步轉碼（采用 Celery 任務隊列，支持任務優先級，熱門用戶視頻優先轉碼）、QUIC 協議（弱網環境下提升上傳速度，降低丟包率）。

想要詳細了解視頻上傳和轉碼的可以看我之前的文章：短視頻上傳與轉碼全流程解析

2.2 視頻推薦與分發

• 推薦流程：用戶打開 APP 后，客戶端調用推薦 API，推薦服務先從 Redis 獲取 “用戶短期興趣標簽”（如最近 1 小時點贊的視頻類型），再從 Spark 離線計算結果中獲取 “用戶長期興趣標簽”，結合用戶地域、設備型號等信息，從 ES 中篩選符合條件的視頻列表，通過負載均衡返回給客戶端；同時，用戶觀看視頻的行為（完播 / 點贊 / 評論）實時上報至 Flink 集群，更新用戶實時興趣標簽，用于下一次推薦。
• 關鍵技術：協同過濾算法（基于用戶行為相似性推薦）、深度學習模型（如 DeepFM，融合用戶特征和視頻特征）、緩存預熱（將熱門推薦列表提前緩存到 Redis，降低推薦服務響應時間）。

想要詳細了解推薦與分發的可以看我之前的文章：5張圖帶你深入短視頻推薦分發背后的技術邏輯

2.3 用戶互動（點贊 / 評論）

圖片

• 點贊流程：客戶端發送點贊請求到互動服務，互動服務先校驗用戶登錄態，再判斷用戶是否已點贊（Redis 查詢，避免重復點贊），未點贊則更新 MySQL（點贊表，按用戶 ID 分表）和 Redis（用戶點贊集合），同時發送 “點贊通知” 消息到 Kafka，消息服務消費后推送通知給視頻作者。
• 關鍵技術：Redis 分布式鎖（避免并發點贊導致的數據不一致）、MySQL 分表（按用戶 ID 哈希分表，支撐億級用戶互動數據存儲）、讀寫分離（點贊查詢走 Redis，寫入走 MySQL 主庫，讀走從庫）、CDN 預熱提升互動拉取的速度。

三、技術難點與解決方案

3.1 海量視頻存儲成本控制

問題拆解

短視頻單文件 10-50MB，億級存量視頻需至少 100PB 存儲空間（按 1 億條、平均 10MB 計算），若全用標準存儲，年成本超千萬元。

且視頻訪問存在 “冷熱分化”—— 近 30 天視頻播放量占總播放量的 80%，老舊視頻訪問頻次極低，全量高成本存儲造成資源浪費。

分層存儲策略

圖片

首先，我們定義 “熱 / 溫 / 冷” 三級數據：

• 熱門視頻（近 7 天播放量 Top10%、或單日播放量 > 1000 次）存對象存儲 SSD 節點（如阿里云 OSS 高性能版），保障毫秒級拉流響應；
• 普通視頻（近 30 天有播放、非熱門）存 HDD 標準節點（成本為 SSD 的 1/2）；
• 歸檔視頻（超過 3 個月無播放、或用戶主動歸檔）遷移至冷存儲（如 OSS 歸檔版，成本僅為標準存儲的 1/5）。

具體實現

通過定時任務（如 Crontab 離線作業，每日凌晨執行）統計視頻播放量，觸發存儲級別自動遷移。

同時提供 “手動歸檔” API，允許創作者將歷史視頻轉入冷存儲，遷移過程中通過 “軟鏈接” 保持播放地址不變，避免用戶感知。

視頻壓縮優化

轉碼階段默認采用 H.265 編碼（對比 H.264，相同清晰度下碼率降低 30%，即 10MB 視頻可壓縮至 7MB），同時針對不同場景做適配：短視頻（15-60 秒）碼率控制在 500-1500kbps（480P→500kbps、720P→1000kbps、1080P→1500kbps），避免碼率冗余；長視頻（超過 1 分鐘）采用 “動態碼率”（VBR），畫面復雜段提高碼率、靜態段降低碼率，進一步節省 20% 存儲。

兼容性處理

針對不支持 H.265 的老舊設備（如部分 Android 7.0 以下機型），轉碼時額外生成 H.264 低碼率版本，客戶端通過設備檢測接口選擇對應格式，兼顧兼容性與成本。

3.2 高并發推流與低延遲播放

問題拆解

峰值時段（如晚間 8-10 點）每秒新增 1000 + 條推流請求，若直接推至源站，會導致源站帶寬瓶頸。

同時百萬級用戶同時拉流時，單節點帶寬壓力超 10Gbps，易出現丟包、延遲（>3 秒），播放卡頓率超 5% 會顯著降低用戶留存。

推流側：邊緣節點

圖片

架構設計

客戶端通過 DNS 解析獲取就近邊緣節點（如用戶在杭州，解析到阿里云杭州邊緣節點），視頻分片先上傳至邊緣節點，邊緣節點完成 “分片校驗 + 臨時存儲” 后，再異步同步至中心源站（采用增量同步，僅傳輸新分片），避免源站直接承接高并發推流。

技術實現

邊緣節點部署 “推流代理服務”（基于 Nginx-RTMP 模塊二次開發），支持 HTTP/2 和 QUIC 協議；客戶端分片上傳時，邊緣節點返回 “分片唯一標識”，若網絡中斷，客戶端可通過標識續傳未完成分片，重傳成功率提升至 99%。

拉流側：CDN 多級緩存 + 播放優化

CDN 緩存策略

采用 “邊緣節點→區域節點→源站” 三級緩存，熱門視頻（播放量 > 10 萬次）直接緩存至邊緣節點（覆蓋全國 300 + 城市），用戶拉流時延遲 < 100ms；普通視頻 緩存至區域節點（如華東、華南區域中心），邊緣節點無緩存時從區域節點拉取，避免直接訪問源站。

客戶端優化

實現 “預加載 + 自適應碼率” 雙機制 —— 用戶播放當前視頻時，后臺預加載下一個推薦視頻（預加載 50% 內容），切換視頻時實現 “無縫播放”；同時客戶端實時檢測網速（每 2 秒計算一次下載速率），若網速 < 1Mbps 自動切換至 480P，1-3Mbps 切換至 720P，>3Mbps 切換至 1080P，卡頓率可控制在 1% 以內。

3.3 實時推薦系統高可用

問題拆解

實時推薦依賴三大環節 ——Flink 實時計算（秒級更新用戶短期興趣）、ES 檢索（毫秒級篩選視頻）、推薦服務 API（聚合結果），任一環節故障（如 Flink 集群重啟、ES 分片異常）都會導致推薦列表空白或返回錯誤內容，影響核心用戶體驗（推薦列表是短視頻 APP 的主要流量入口，不可用會導致 DAU 下降 40%+）。

多級降級預案

圖片

一級降級（實時引擎故障）

當 Flink 實時計算集群延遲 > 5 秒（通過監控告警檢測），推薦服務自動切換至 “離線推薦 + 短期緩存” 模式 —— 使用 Spark T+1 離線計算的用戶長期興趣標簽，結合 Redis 緩存的 “用戶最近 1 小時互動視頻類型”（如最近點贊過 “美食”），生成推薦列表，避免實時數據缺失導致的興趣偏差。

二級降級（ES 故障）

當 ES 集群健康度 <90%（如分片不可用），推薦服務直接返回 Redis 中緩存的 “熱門視頻列表”（每 10 分鐘更新一次，存儲 Top1000 條熱門視頻），同時標記 “降級狀態”，前端顯示 “熱門推薦” 標識，降低用戶感知。

三級降級（推薦服務過載）

通過 Sentinel 配置推薦 API 的 QPS 閾值（如單節點 1000QPS），當并發超閾值時，自動返回 “簡化推薦列表”（僅返回 20 條視頻，而非默認 50 條），同時拒絕非核心推薦請求（如 “相似視頻推薦”），優先保障首頁主推薦流可用。

數據一致性保障

離線推薦結果預加載

每日凌晨 Spark 離線計算完成后，將用戶長期興趣推薦列表提前寫入 Redis（按用戶 ID 分片存儲），推薦服務優先從 Redis 讀取，減少 ES 訪問依賴；同時通過 “版本號機制” 確保 Redis 與 ES 數據同步 —— 當 ES 數據更新時，同步更新 Redis 中的版本號，推薦服務發現版本不一致時觸發增量更新。

故障恢復自動切換

通過監控系統（如 Prometheus+Grafana）實時檢測各環節狀態，當故障環節恢復（如 Flink 延遲恢復正常、ES 分片重新分配完成），推薦服務自動切換回正常模式，切換過程無感知（通過雙活服務部署，舊模式服務繼續處理存量請求，新模式服務承接增量請求，待存量請求處理完后下線舊模式）。

四、小結：從 “滿頭問號” 到 “架構落地”，我們還能走得更遠

寫這篇架構拆解時，我總會想起第一次接 “做短視頻系統” 需求的場景 —— 對著產品經理畫的 “某音同款” 原型圖，手里的筆懸了半小時，滿腦子都是 “這億級視頻存哪里”“百萬并發怎么抗” 的焦慮。

但當把架構拆成 “接入層擋請求、核心服務做流轉、算法引擎給智能、基礎組件托底” 四層后，突然發現復雜問題也能 “化整為零”。

回頭看全文，我們其實只做了三件事：把模糊需求拆成技術模塊（比如把 “視頻上線” 拆成上傳、轉碼、審核三步），給每個模塊選對工具（推流用邊緣節點卸壓、推薦用 Spark+Flink 雙引擎），給關鍵痛點留好退路（存儲分冷熱控成本、推薦做三級降級保可用）。

這些方案沒有什么 “黑科技”，但勝在落地性 —— 畢竟對開發者來說，能 扛住流量、控住成本、不出故障的架構，才是好架構。