短視頻流媒體平臺的系統設計

1. 功能需求:

我們的系統有兩類參與者

內容創作者

• 上傳任何類型的視頻(格式 + 編解碼器)• 視頻可以被刪除 • 視頻元數據 • 必填項: 標題,作者,描述 • 選填項: 分類 / 標籤列表 • 可以隨時更新 • 當視頻對觀衆可用時,向內容創作者發送電子郵件

不在討論範圍內:

• 直播 • 視頻修改 • 支付和訂閱

用戶 / 觀衆

• 需要註冊 + 訂閱 • 使用自由文本搜索視頻屬性 / 元數據 • 在以下設備上觀看視頻 • 任何設備(移動設備,平板電腦,桌面電腦)• 使用網絡瀏覽器 / 專用應用 • 在不同的網絡條件下

2. 非功能需求:

內容創作者

• 可擴展性 •1000 名用戶平均每週上傳 1 個視頻 • 視頻可以達到 60 FPS,時長數小時,高分辨率且未壓縮 • 視頻大小約 50 GB(>50 TB / 周)• 可用性(低停機時間)•99.9% 的正常運行時間 • 性能 • 響應時間在 99pt 時 < 500 ms• 視頻在幾小時內對用戶可用 • 數據一致性(CAP)• 在我們的案例中,對於內容創作者:一致性 (CP) > 可用性 (AP)

用戶 / 觀衆

• 可擴展性 • 數億每日用戶 • 可用性 •99.9% 的正常運行時間 • 性能 • 響應時間在 99pt 時 < 500 ms• 無論用戶的設備大小和網絡如何,播放時都無緩衝時間 • 數據一致性(CAP)• 在這種情況下,可用性 (AP) > 一致性 (CP)

3. 視頻傳輸流程理解:

點播視頻傳輸圖:

視頻編解碼器: H.264 / AVC, H.265 / HEVC, VP9, AV1

音頻編解碼器: AAC, WAV, MP3, WMA

向終端用戶傳輸壓縮視頻 我們如何爲個別用戶決定比特率?根據設備決定比特率 風險:

• 高估用戶的帶寬 • 低估用戶的帶寬

如果我們只考慮設備,可能會有很多網絡變化,最好的方法是考慮網絡條件。這種技術稱爲自適應比特率 (ABR)。在這種技術中,我們基本上將不同比特率的轉碼視頻流分解成通常爲 5-10 秒的片段,並在清單文件中引用它們,所以當用戶開始播放視頻時,它首先下載清單文件並緩衝前 3 個片段,之後它會重新評估帶寬,從更高或更低比特率的版本中選擇片段。如果您想了解更多關於 ABR 的信息,請點擊這裏

最後一步是我們的轉碼視頻作爲包被提供,不同的瀏覽器,應用遵循不同的協議和交付格式,所以我們必須將我們的視頻打包成每一種協議,並且我們必須使用 DRM(數字版權管理)來保護我們的視頻。

4. 符合內容創作者和用戶功能需求的系統架構圖:

以下圖表符合我們所有的功能需求。

5. 符合非功能需求的系統架構圖:

現在是時候讓我們的應用程序可擴展,以滿足非功能需求了。

內容創作者:

可擴展性

• 由於上傳視頻的頻率並不很高,所以我們可以在我們的 Web 應用和視頻數據服務前面放置負載均衡器,並運行每個服務的幾個實例。• 相反,每個視頻的體積非常大,所以我們需要識別我們流程中的瓶頸,因此之前我們的視頻文件首先被髮送到 API 網關,然後是 web 應用,最終 web 應用將文件存儲到我們的對象存儲中,但是我們可以使用簽名 URL,因爲我們在 API 和 web 應用服務上浪費了大量的網絡和計算能力。簽名 URL 將允許直接訪問對象存儲的時間和權限有限的訪問。

可用性

• 通過在我們的服務中使用冗餘,我們已經提供了高可用性,此外,通過使用雲託管的對象存儲進行轉碼和打包服務,我們可以直接獲得可用性。對於最後一步,我們需要在 NoSql 數據庫上進行復制,以便視頻服務。

性能

• 如果我們的所有內容創作者都想在同一天或同一時間上傳視頻怎麼辦?我們可能無法在合理的時間內處理它們。爲了確保成功,我們需要在視頻處理管道中提供足夠的並行性。

數據一致性

• 爲了隨時更新元數據,我們需要選擇視頻服務數據庫的 DB 技術或配置,以提供一致性(CP)在分區容錯上優先於可用性(AP)。

以上所有內容,我們現在已經完成了內容創作者的所有非功能需求。

用戶 / 觀衆:

可擴展性

• 爲了滿足數百萬用戶的請求,我們需要將搜索服務放在負載均衡器後面,並將其作爲一組相同的實例運行,然後複製搜索數據庫,以便我們可以支持新請求並將它們分散到多個數據庫實例中。

可用性

• 關於高可用性,我們已經基本上覆蓋了,我們需要做的唯一事情是在多個隔離區域地理位置運行我們的系統,例如美國西部,美國東部,亞太地區,歐洲。

性能

• 解決性能問題的最重要組件是添加 CDN。此外,我們不會更新視頻數據服務與對象存儲中的視頻位置,而是將 CDN url 添加到視頻服務數據庫。所以現在當用戶通過 API 請求視頻 URL 時,它將提供指向 CDN 的 url,並且它將從最近的邊緣服務器將內容提取到用戶的設備,這將導致視頻的前兩個片段更快地到達用戶,之後自適應比特率流媒體將啓動,並將緩衝時間減少到幾乎爲零。

數據一致性

• 搜索服務使用 CQRS(事件驅動)模式從視頻數據服務獲取數據,這已經保證了最終一致性,所以我們只需要配置搜索數據庫,優先考慮可用性(AP)而不是一致性(CP)。

通過以上所有內容,我們成功完成了所有非功能需求,打造了一個高度可擴展的視頻流媒體平臺

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/nYrEWtH7g-twMLFO7bjvIA