Facebook是如何支援80萬并發視訊流直播的

具備建構橫跨全球的分布式服務能力的公司寥寥無幾，甚至比擁有核武器的國家還要少。然而，facebook就是這樣的一個公司，它的視訊流直播系統facebook live就是一個橫跨世界的分布式服務。facebook的ceo mark zuckerberg說：

我們做了一個重大決定，把更多的精力集中在視訊直播上。因為直播是一種新興的方式，跟過去五年甚至十年的那些離線視訊不一樣……我們正迎來視訊的新黃金時期。如果把時間快進五年，人們在facebook上看到的和他們每天分享的大部分内容都是視訊，這對我來說一點也不驚奇。

如果你身處廣告行業，還有什麼比獲得源源不斷的可作為廣告載體的内容更能激動人心？這些内容不拘一格地出現，持續增長，永不停息。谷歌在這上面打起了如意算盤，開始把廣告業務的重心壓在呈指數級增漲的web上。

能夠展現facebook在流視訊方面具有強大能力的例子，當屬那個兩人使用橡皮圈撬開一個西瓜的視訊。這個視訊時長45分鐘，高峰時段有80萬人同時線上觀看，這些觀衆還給出了30萬份評論。對于一個擁有15億使用者的社交網絡來說，這樣的并發量可以說已經達到了病毒級規模。

2015年的super bowl（美國國家美式足球聯盟年度冠軍賽）有1億1千4百萬觀衆，其中大概有236萬觀看的是視訊直播。在2015年的e3遊戲展期間，twitch直播系統高峰期使用者達到84萬。9月16日的共和黨辯論在高峰時有92萬1千人同時線上觀看直播。

這麼看來，facebook也已經是名列前茅了。這裡要注意的是，facebook在同一時間還要處理其它大量的視訊流。

有一篇文章引用了facebook首席産品官chris cox的話，他說facebook：

有超過100人同時工作在live項目上（剛開始隻有12個人，現在有150多人） 希望并發直播流的服務能力可以達到百萬級别 希望可以做到單個流支援百萬并發使用者，還能無縫地支援跨裝置、跨地域的視訊流服務

cox說“我們發現這是一個非常具有挑戰性的基礎設施問題”。如果把我們解決這個問題的細節公之于衆應該會很有趣的吧？天啊！不過等等，我們會這麼幹的！

federico larumbe來自facebook流量團隊，他負責的緩存系統支撐着facebook的cdn和全局負載均衡器。他為我們帶來了“橫向擴充facebook live”的出色演講，分享了live的一些工作細節。

下面是我對這次演講做的筆記，它真的令人印象深刻。

最初的故事

live是一個可以讓人們實時分享視訊的新項目。 live在2015年4月份啟動，當時隻能通過mentions使用，作為少數高端人士與他們粉絲之間的互動工具。 在之後的一年裡，産品不斷改進，協定也在疊代更新。　　 他們開始使用hls，也就是http live streaming。iphone開始支援live，并允許他們使用現有的cdn架構。 同時對rtmp（real-time messaging protocol）進行調研，rtmp是一個基于tcp的協定。手機端分别有一個視訊流和音頻流被發送到live stream伺服器。　　　　 優點：rtmp縮短了從廣播者到觀看者之間的延遲，這個對廣播來說意義重大。減少幾秒鐘的延遲，從使用者體驗方面來說就是一個很大的改進。 缺點：需要全新的架構，因為它不是基于http的。需要開發新的rtmp代理，這樣才能大規模使用。 同時調研了mpeg-dash（基于http的動态自适應流）。　　　　 優點：相比hls，它可以節省15%的空間。 缺點：它支援自适應比特率，編碼品質取決于網絡的吞吐量。 2015年12月，在多個國家啟動了該項目。

不同的直播視訊引起的問題

之前提到的撬西瓜視訊的流量模式：　　 剛開始增漲很快，在幾分鐘内就超過每秒100個請求，然後持續增漲，直到視訊結束。 然後流量呈斷崖式下降。 換句話說，流量的形狀就像一個尖刺。 直播視訊跟一般的視訊不一樣，它的流量模式呈尖刺狀。　　 直播視訊更吸引人，比一般視訊會多出3倍以上的浏覽量。 直播視訊會出現在顯眼位置，更有可能被浏覽到。 網站的忠實使用者會收到通知，是以有更多的人可能會看到視訊。 尖刺流量模式會給緩存系統和負載均衡器帶來一些問題。 緩存系統問題有可能很多使用者同時觀看視訊直播。這樣會造成驚群（thundering herd）問題。 尖刺流量模式會給緩存系統帶來壓力。 視訊按秒分段存儲，緩存視訊分段的伺服器有可能在流量高峰時過載。 全局負載均衡問題facebook的pop（point of presence）伺服器分布在世界各地，流量通過全局進行分發。 如何防止高峰流量拖垮pop是個具有挑戰性的問題。

全局架構

視訊直播流從主播端到觀衆端的流程是這樣的：

主播在他們的手機上發起一個視訊直播。 手機把rtmp流發送到live stream伺服器上。 live stream伺服器對視訊流進行編碼并轉成多種比特率。 伺服器為每種比特率持續地生成mpeg-dash分段。 分段被存儲在資料中心的緩存裡。 分段從資料中心的緩存轉發到pop的緩存裡。 觀衆端接收直播流。 觀衆端裝置上的播放器以一定的速率從pop緩存裡擷取分段。

如何橫向擴充

在資料中心緩存和pop緩存之間存在一個多路分發點。使用者通路的是pop緩存，而不是資料中心緩存，而且有很多pop緩存分布在世界各地。 在每個pop裡也有多路分發機制。　　 pop内部被分為兩層：一層是http代理，一層是緩存。 使用者向http代理請求分段，代理檢查分段是否已經在緩存裡，如果是，就傳回分段，否則請求會被發送到資料中心。 不同的分段被存儲在不同的緩存裡，這樣有助于在多個緩存主機間進行負載均衡。

避免資料中心出現驚群效應

如果所有使用者同時對同一個分段發起請求會出現什麼情況？ 如果分段不在緩存裡，所有請求都會被發送到資料中心。 合并請求。在pop緩存裡使用合并請求可以減少發送請求的數量，這樣隻有一個請求會被發送給資料中心。其它請求會等待第一個請求傳回的響應，然後把資料傳回給使用者。 增加一個新的緩存層，避免出現熱點服務問題。　　 所有使用者向的請求都發給同一個主機會造成該主機過載。 在代理裡增加緩存層。隻有第一個請求會通路到緩存，代理會處理剩下的請求。

pop還存在風險，需要全局負載均衡來救場

資料中心的驚群問題得到了解決，但pop仍然存在風險。live存在的一個問題是，在pop達到負載均衡器的負載名額之前，高峰流量已經讓pop發生過載。 每個pop的伺服器數量和連接配接帶寬都是有限的。如何避免pop在高峰時發生過載？ 一個叫cartographer的系統把子網跟pop映射起來，它會對每個子網和pop之間的延時進行監測。 在知道每個pop負載的情況下，使用者請求會被發送到距離最近的可用pop上。代理有一個負載計數器記錄了它們的負載情況。通過收集這些計數器我們就可以知道每個pop的負載情況。 現在出現了對pop處理能力的限制和最小化延遲的優化問題。 控制系統在收集名額和作出反應方面存在延時。 他們把名額收集時間從一分半鐘減少到3秒，不過3秒仍然是延遲。 解決方案是對負載進行預測。 他們實作了一個負載評估器，通過前一個負載和目前負載來推斷後面的負載。　　 如果目前負載是增加的，那麼評估器如何能推斷下一個負載會減弱？ 他們使用了三次樣條插值（cubic spline interpolation）功能。 先獲得第一個和第二個導數，如果速度是正數，說明負載在增加。如果加速度是負數，那麼說明速度在下降，并最終變成零。 三次樣條插值可以預測更複雜的流量模式，不僅僅是線性模式。 避免振動。 插值功能同時解決了振動問題。 名額收集和反應出現延遲說明資料已經過時。插值會減小誤差，預測更準确，同時減少振動。這樣負載就可以接近預設值。 目前的預測是基于前三次的時間間隔，每個間隔30秒，是以得出的結果幾乎是實時的。

測試

想辦法讓pop過載。 建構一個負載測試服務，為pop模拟直播流量。 模拟10倍于真實資料的負載。 模拟每次請求一個分片的用戶端。 這個測試系統有助于發現和修補負載評估器的漏洞，用以調整配置參數，并驗證用于解決驚群問題的緩存層是否工作正常。

上傳的可靠性

實時上傳視訊是一個挑戰。 舉個使用100kbps到300kbps的網絡帶寬上傳視訊的例子。 音頻需要64kbps的吞吐量。 标準分辨率的視訊需要500kbps的吞吐量。 手機的自适應碼率用于協調視訊跟音頻之間的吞吐量內插補點。視訊的碼率根據實際可用的網絡帶寬進行調整。 手機根據已認證rtmp上傳的位元組數和上一個間隔的平均權重來決定上傳的碼率。

未來的方向

使用推送機制代替輪詢機制，在發送分片請求前，使用http/2把分片推送到pop上。

本文轉自d1net（轉載）