【乾貨】彈性支撐百萬級別直播流的樂視雲「月光寶盒」如何煉成？

公司介紹

樂視雲計算有限公司(以下簡稱樂視雲)是新樂視上市體系中核心業務版塊之一，負責新樂視體系所有基礎設施服務和雲計算服務。樂視雲圍繞視頻雲和物聯雲兩大方向開展業務，致力成為領先的家庭互聯智能娛樂雲技術提供者，以物聯云為核心創造更智能的家居社區解決方案。

樂視雲在視頻行業有強大的技術儲備，在視頻領域中的點播、直播、分發、媒體技術、視頻內容理解等方面處於行業領先地位;而物聯雲將圍繞家居安全、智能互聯、環境健康等方面提供全部解決方案。

2015年到2017年的2年間，樂視雲曾成功服務於除新樂視外上萬家企業客戶，如熊貓TV、戰旗TV、快手、人人網、鳳凰網、百度視頻、OPPO等大型企業;在廣電領域，樂視雲先後與中國藍TV、天府TV、四川網路廣播電視台等廣電企業建立開放型戰略合作，促進新型全媒體產業融合。2016年曾融資10億人民幣，是樂視生態第四個獨角獸。

項目背景

在觀看視頻直播中，難免會發生因為各種打斷而錯過一些精彩片刻的情況，這個時候，如果我們能

快速穿越回去，會是怎樣一種體驗?樂視雲「月光寶盒」可以完美彌補遺憾，讓精彩不再錯過。

項目挑戰

「月光寶盒」是樂視雲直播 PaaS
平台的一個重要服務，可以完美解決直播過程中任意時間段的時移回看，也可以在直播結束後，提供瞬時秒回功能，快速將直播信號轉為點播信號進行分發，大幅提升了直播觀看體驗，也同時給直播運營提供了更多的可能。月光寶盒歷經三次產研迭代，見證了直播流由萬增至百萬的快速增長，一路上我們遇到了哪些挑戰?直播流的分配策略是如何進化的?源站的切片、索引存儲需要做出哪些升級?以及在持續迭代過程中如何確保平滑升級等等問題，接下來我們將從「月光寶盒」三次大的版本迭代中做出解答。

月光寶盒 V1.0

直播 PaaS 平台由原支撐樂視集團業務的直播後台技術部蛻變而成，已經持續服務於樂視網、樂視電視、機頂盒、樂視體育、樂視音樂等超過 5 年時間,
早期的直播流量在萬級別(註：直播流 ID 個數，可以理解為一個直播流就是一路信號)，直播信號通常以 7*24
小時長直播為主，發布會、演唱會等短直播為輔(註：這類短直播無直播內容時，通常會配置一個指定的備片來持續代替直播信號源，以提升斷流時用戶播放體驗)，因此在
V1.0
架構中，這階段的直播生產調度分配演算法採用簡單的配置策略，將直播流與設備組進行關聯綁定，直播流對應的切片與索引採用簡單的本地存儲。直播、時移回看、打點錄製均在該組設備中並行提供服務。

V1.0 架構圖

註：

綠色表示直播流長期處於使用狀態。

紫色表示直播信號暫時中斷，但源站配置了播放備片功能，會播放備片信號，提高直播斷流體驗。

附：左圖為正常直播信號，右圖為直播信號中斷時播放的備片。

隨著直播 PaaS
平台的開放，海量直播流的接入，而商業直播的需求主要以秀場、發布會等間隔較短的直播為主，此時如果仍按照原有均衡分配直播流策略，每個直播都分配單獨伺服器，會導致伺服器數量成倍增加，資源成本陡增，為解決這個問題，月光寶盒架構也升級至
V1.1。

月光寶盒 V1.1

在 V1.1
版本中，直播流均按需生產，為了確保客戶所接入的流量安全，調度會同時分配給主備兩台設備來生產該流，在主節點故障時自動執行主備切換，確保對用戶播放無感知。

隨著業務的快速增長，日活直播快速上升，平台對直播源站集群進行了擴容，但由於直播流分配策略會優先與時移數據綁定(註：該策略為確保全程回看數據在同台設備連續)，因此在實際運行的過程中可能會出現比較嚴重的偏壓問題，會導致比較明顯的熱點問題，需要通過集群上報流監控狀態判斷是否需要對備流進行遷移，以實現集群的再均衡。

V1.1架構圖

註：

虛線箭頭表示發生偏壓時，部分直播流發生遷移。

綠色表示正在播放的直播流。

紅色表示直播流即將被遷移。

黃色表示直播流被遷移後。

通過流遷移的方式我們緩解了熱點問題，但這種方式有一定的滯後性，我們需要新的架構來解決這個問題，在介紹新架構方案前，首先快速介紹下直播業務裡面用到一些協議和文件，HLS(Http
Live Streaming)是由 Apple 公司定義的用於實時流傳輸的協議，HLS 基於 HTTP 協議實現，傳輸內容包括兩部分，一是 M3U8
描述文件，二是 TS 媒體文件。M3U8 文件是用文本方式對媒體文件進行描述，由一系列標籤組成。

隨著業務持續增長，整個直播集群的存儲壓力會變得比較突出，因此需要儘快消除 IO 瓶頸。在此背景下，我們首先將 TS 切片遷移到了
LeS3(樂視雲對象存儲系統), 但對於視頻索引的存儲仍然按照主備方式管理，所以下一步重點就變成了尋找存儲 M3U8
的索引集群存儲解決方案，由於不同直播流對切片設置大小不一(通常設置在 2~10s)，譬如北京其中一個集群最大峰值寫入約在 3w
左右，業務屬於寫多讀少，對於傳統主從 RDS 來說，單機無法承受，需要做分庫分表，而分庫分表有很多弊端，比如對業務侵入太多、應用不友好，普遍的採用 Proxy
方案不但對技術有要求，而且還有非常多的局限性，視頻直播需要靈活的擴展性，而分庫分表對再擴容的成本非常高，會為業務埋下隱患。這期間我們接觸到了
TiDB，其支持多活、無單點、支持橫向擴容特性且兼容 MySQL 等特性與我們的業務需求非常吻合，加之 TiDB
安裝部署、監控等細節做得非常到位，我們決定測試看看效果。

月光寶盒 V1.2

經過一周左右對TiDB的常用場景測試、壓測，測試結果比較符合預期，從存儲容量、QPS、響應時間來看，均可支持我們「快速穿越執行時移回看」的需求。測試期間也跟官方的同學進行技術交流，確定了後續生產環境中如：部署架構、設備選型、表結構及索引優化。在生產環境的
TiDB 生產集群上線後，我們將線上原有直播流的 HLS 回看的索引在原 V1.1 架構進行本地存儲外，同步複製至 TiDB
中，以便於真實生產環境中來驗證TiDB的穩定性。觀察一月多，運行平穩，期間我們做部分故障演練，如將PD、TiKV、TiDB中某一台重啟，並未出現服務不可用或丟數據的情況!接下來對北京一個直播集群月光寶盒服務進行了試點改造，採用灰度切流方式逐步將直播流的時移、回看、秒回請求切至TiDB
，運行穩定。目前全國各地直播集群的月光寶盒服務跑在TiDB服務之上。

v1.2 架構圖

附一張 TiDB 在月光寶盒 V1.2 中的架構圖：

總結回顧

前面已將「月光寶盒「歷經3個階段詳述，最後我們再用一張表做下簡單的回顧。

上線效果數據說明

通過將 M3U8 數據統一存儲到一套 TiDB 集群，大幅度簡化直播源站的結構，從源頭解決負載偏壓、擴展的問題，同時 TiDB
很好的解決了這類寫多讀少的業務場景，具體體現如下：

● 單機 HLS 設備生產性能提升 200%。

● 簡化直播流分配調度策略，消除集群內偏壓問題。

● 簡化直播源站結構，消除上下游關聯繫統耦合。

● TiDB 天然的高可用提升了系統的可用性。

● 依賴 TiDB 的負載均衡，優雅的解決了直播流量彈性擴展的問題。

現狀及計劃

目前月光寶盒 v1.2 已持續穩定的服務於標準直播、移動直播、直播CDN等三大業務線，其中北京一個核心直播集群的 TiDB 峰值 寫入 QPS 達到
2.5W 左右，經過 CDN 及 HLS_Consumer 的雙重緩存後讀請求峰值約在 5k 左右，下一步我們會將直播內部的一套數據分析系統也遷移到
TiDB中。

大家對「月光寶盒」研發技術感興趣，也可以關注樂視雲公眾賬號，感興趣同學達到一定數量後，我們會舉辦一些線下活動進行技術分享。

單個直播集群對應的 TiDB 集群總體配置如下：

作者簡介：劉斌，樂視雲工程師，主要參與樂視直輪播、商業直播 PaaS 架構設計迭代。

招聘

視頻雲基礎平台正在招聘「流媒體研發/圖像視頻演算法/深度學習/JAVA開發工程師」
感興趣的同學可將簡歷發送至「wangxiaoyu1@le.com」

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！