# Facebook 如何向 80 萬同時觀看者直播 > 原文： [http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html)  與擁有 核武器的國家相比，很少有公司知道如何建立全球性的分布式服務。 Facebook 是其中一家公司， [Facebook Live](https://www.facebook.com/livemap/) ，Facebook 的 [新](https://live.fb.com/about/) 實時視頻 流產品，就是這些服務之一。 Facebook CEO [馬克·扎克伯格](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)： > 我們做出的重大決定是將我們的許多視頻工作重點轉移到 Live 上，因為這是一種新興的新格式； 而不是過去五到十年一直在線的那種視頻……我們正在進入視頻的新黃金時代。 如果您快進五年，人們在 Facebook 上看到并每天分享的大部分內容都是視頻，我不會感到驚訝。 如果您從事的是廣告業務，那么比提供永無止境，始終在擴展且可自由生成的廣告就緒內容更好？ 當 Google [開始在呈指數增長的網絡上投放廣告時，就利用了](http://www.wsj.com/articles/SB108319881076696889) 來進行經濟分析。 Facebook 的流媒體表演的一個例子是兩個人的 45 分鐘視頻 [用橡皮筋爆炸西瓜](https://www.buzzfeed.com/brendanklinkenberg/this-exploding-watermelon-was-facebook-lives-biggest-hit-to) 。 它達到了超過 80 萬同時觀看者的頂峰，這些評論者還收集了 30 萬以上的評論。 這就是您可以通過擁有 15 億用戶的社交網絡產生的病毒規模。 作為比較 [1.14 億](http://www.statista.com/statistics/216526/super-bowl-us-tv-viewership/) 觀看了 2015 年超級碗的觀眾，平均 [觀看者有 236 萬 實時流中的](http://money.cnn.com/2015/10/26/media/nfl-yahoo-live-stream-results/) 。 Twitch 的 [840,000](http://www.geekwire.com/2015/amazons-twitch-attracts-monster-audience-at-e3-with-21m-viewers-tuning-in-online/) 觀眾人數在 2015 年 E3 達到頂峰。9 月 16 日的共和黨辯論在 [921,000 達到頂峰 ]](http://www.politicususa.com/2015/10/14/debate-watched-democratic-debate.html) 同時直播。 因此，Facebook 處于最新狀態。 請記住，Facebook 也會同時有大量其他流。 一篇有線文章 [引用了](http://www.wired.com/2016/04/facebook-really-really-wants-broadcast-watch-live-video/) Facebook 首席產品官 Chris Cox，他說 Facebook： * 有超過**個**現場直播人員。 （[從[12]開始](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)，現在該項目有 150 多名工程師） * 需要能夠提供**數百萬個同時流**而不會崩潰。 * 需要能夠在流上支持**數百萬同時觀看者，以及全球不同設備和服務提供商之間的無縫流。** Cox 說：“事實證明這是一個非常困難的基礎架構問題。” 如果我們有一些有關如何解決該基礎結構問題的詳細信息，這會很有趣嗎？ 禍是我們。 但是等等，我們做到了！ [Federico Larumbe](https://www.linkedin.com/in/federicolarumbe) 來自 Facebook 的流量小組，該小組致力于為 Facebook 的 CDN 和全球負載平衡系統提供支持的緩存軟件，并發表了精彩的演講： [擴展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) ，他在其中分享了有關 Live 工作方式的一些詳細信息。 這是我在演講中的發言。 令人印象深刻 ## 起源故事 * Facebook 是一項新功能，允許人們實時共享視頻。 （請注意，這對于 Facebook 來說只是另一個功能）。 * 于 2015 年 4 月推出，只有名人才能通過 [提及應用](https://www.facebook.com/about/mentions/) 作為與粉絲互動的媒介使用。 * 這是產品改進和協議迭代開始的一年。 * 他們以 HTTP 實時流媒體 [HLS](https://en.wikipedia.org/wiki/HTTP_Live_Streaming) 開頭。 它受 iPhone 支持，并允許他們使用現有的 CDN 架構。 * 同時開始研究 [RTMP](https://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) （實時消息協議） ，這是一種基于 TCP 的協議。 從手機發送到實時流服務器的是視頻流和音頻流。 * 優點：RTMP 在廣播者和觀看者之間具有較低的終端等待時間。 在人們相互交流的交互式廣播中，這確實有所作為。 然后，降低等待時間并減少幾秒鐘的延遲，將使體驗有所不同。 * 劣勢：由于它不是基于 HTTP 的，因此需要一個完整的體系結構。 需要開發新的 RTMP 代理以使其擴展。 * 還研究了 [MPEG-DASH](https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) （基于 HTTP 的動態自適應流）。 * 優勢：與 HLS 相比，它的空間效率高 15％。 * 優點：它允許自適應比特率。 編碼質量可以基于網絡吞吐量而變化。 * [吹笛者中出壓縮解決方案](https://www.crunchbase.com/organization/pied-piper#/entity) ：（開個玩笑） * 于 2015 年 12 月在數十個國家/地區推出。  ## 實時視頻與眾不同，這會引起問題 * 前面提到的西瓜視頻的流量模式： * 最初的上升非常陡峭，在幾分鐘之內達到了每秒 100 多個請求，并持續增長直到視頻結束。 * 然后，流量像石頭一樣下降。 * 換句話說：流量非常大。  * 實時視頻與普通視頻不同：它會導致**尖峰** **流量模式**。 * 實況視頻更具吸引力，因此觀看**的**比普通視頻多 3 倍。 * 實時視頻出現在新聞源的頂部，因此被觀看的可能性更高。 * 通知會發送到每個頁面的所有粉絲，以便另一組可能會觀看視頻的人。 * 高峰流量會導致緩存系統和負載平衡系統出現問題。 * **緩存問題** * 很多人可能希望同時觀看直播視頻。 這是您的經典 [雷電牧群問題](https://en.wikipedia.org/wiki/Thundering_herd_problem) 。 * 尖刻的流量模式給緩存系統帶來壓力。 * 視頻被分割成一秒鐘的文件。 當流量激增時，緩存這些段的服務器可能會過載。 * **全局負載平衡問題** * Facebook 在全球分布 [個存在點](https://en.wikipedia.org/wiki/Point_of_presence) （PoP）。 Facebook 流量在全球范圍內分布。 * 挑戰在于防止峰值使 PoP 過載。 ## 大圖片架構 這就是直播流從一個廣播公司到數百萬觀眾的方式。 * 廣播員在其手機上開始直播視頻。 * 手機將 RTMP 流發送到實時流服務器。 * 實時流服務器解碼視頻并將代碼轉換為多個比特率。 * 對于每個比特率，將連續生成一秒鐘的 MPEG-DASH 段。 * 段存儲在數據中心緩存中。 * 從數據中心緩存段被發送到位于存在點的緩存（PoP 緩存）。 * 觀看者在觀看時會收到一個實時故事。 * 他們設備上的播放器開始以每秒 1 個的速率從 PoP 緩存中獲取片段。 ## 它如何縮放？ * 數據中心高速緩存和**許多 PoP 高速緩存**之間有一個**乘法點**。 用戶訪問 PoP 緩存，而不是數據中心，并且全世界分布著許多 PoP 緩存。 * 另一個乘數是每個 PoP 中的**。** * 在 PoP 中有**兩層**：一層 HTTP 代理和一層緩存。 * 查看器從 HTTP 代理請求段。 代理檢查該段是否在緩存中。 如果在緩存中，則返回該段。 如果不在緩存中，則將對該段的請求發送到數據中心。 * 不同的**段存儲在不同的緩存**中，從而有助于跨不同的緩存主機進行負載平衡。 ## 保護數據中心免受雷電襲擊 * 當所有觀眾同時請求相同的片段時會發生什么？ * 如果該段不在高速緩存中，則將向每個查看器發送一個請求到數據中心。 * **請求合并** 。 通過將請求合并添加到 PoP 緩存中，減少了請求數量。 僅第一個請求發送到數據中心。 其他請求將一直保留，直到第一個響應到達并將數據發送給所有查看者為止。 * 新的緩存層已添加到代理，以避免 **Hot Server 問題**。 * 所有查看器都發送到一個緩存主機，以等待該片段，這可能會使主機過載。 * 代理**添加了緩存層**。 實際上，只有第一個對代理的請求才向緩存發出請求。 以下所有請求均直接從代理服務。 ## PoP 仍然處于危險之中-全局負載平衡正在救援 * 因此，保護??數據中心不受雷電群問題的影響，但 PoP 仍然處于危險之中。 Live 的問題是尖峰非常大，以致 PoP 可能在 PoP 的負載度量達到負載平衡器之前過載。 * 每個 PoP 具有數量有限的服務器和連接性。 如何防止峰值導致 PoP 過載？ * 名為 Cartographer 的系統將 Internet 子網映射到 PoP。 它測量每個子網和每個 PoP 之間的延遲。 這是延遲測量。 * 測量每個 PoP 的負載，并將每個用戶發送到具有足夠容量的最近 PoP。 代理中有一些計數器可以衡量它們承受的負載量。 這些計數器是匯總的，因此我們知道每個 PoP 的負載。 * 現在存在一個優化問題，該問題會考慮容量限制并最大程度地減少延遲。 * 使用控制系統時，存在測量延遲和反應延遲。 * 他們將負載測量窗口從 1.5 分鐘更改為 3 秒，但仍然有 3 秒的窗口。 * 解決方案是在實際發生負載之前 **預測負載** 。 * 實施了**容量估算器**，將每個 PoP 的先前負載和當前負載外推到未來負載。 * 如果負載當前正在增加，預測器如何預測負載將減少？ * **三次樣條**用于 [插值](https://en.wikipedia.org/wiki/Spline_interpolation) 功能。 * 取一階和二階導數。 如果速度為正，則負載將增加。 如果加速度為負，則表示速度正在降低，最終將為零并開始降低。 * 三次樣條比線性插值預測更復雜的交通模式。 * **避免振蕩** 。 此插值功能還解決了振蕩問題。 * 測量和反應的延遲意味著對過時的數據做出決策。 插值可減少誤差，更準確地進行預測并減少振蕩。 因此負載可以更接近目標容量 * 當前預測是基于 最近的三個間隔 ，其中每個間隔為 30 秒。 幾乎是瞬時負載。 ## 測試 * 您需要能夠使 PoP 過載。 * 構建了一個負載測試服務，該服務在 PoP 上全局分布，以模擬實時流量。 * 能夠模擬 10 倍的生產負荷。 * 可以模擬一次請求一個片段的查看器。 * 該系統有助于揭示和修復容量估計器中的問題，以調整參數，并驗證緩存層是否解決了雷電群問題。 ## 上傳可靠性 * 實時上傳視頻具有挑戰性。 * 以具有 100 至 300 Kbps 可用帶寬的上載為例。 * 音頻需要 64 Kbps 的吞吐量。 * 標清視頻需要 500 Kbps 的吞吐量。 * 手機上的自適應編碼用于調整視頻+音頻的吞吐量不足。 視頻的編碼比特率根據可用的網絡帶寬進行調整。 * 決定上傳比特率的方法是在手機中通過測量 RTMP 連接上的上傳字節來完成，并且對最后間隔進行加權平均。 ## 未來方向 * 研究一種推送機制，而不是請求拉機制，利用 HTTP / 2 在請求分段之前將其推送到 PoP。 ## 相關文章 * [關于 HackerNews](https://news.ycombinator.com/item?id=11987654) * [擴展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) * [為什么 Facebook 和 Mark Zuckerberg 都參與直播視頻](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video) * [連接世界：Facebook 網絡基礎架構](http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf) * [Gamoloco](https://gamoloco.com/) 跟蹤 1476093 個頻道的實時視頻統計信息。 Google Chrome 瀏覽器告訴我您的網站已感染惡意軟件。 也許是個調皮的廣告？ 我很樂意在具有如此高流量的平臺上工作。 12 位工程師可以毫無問題地做到這一點。 很少有人可以在應用程序上工作，甚至可以進行額外的數據壓縮，而在主平臺上則很少。 我什至可以處理 100-200k 觀眾的實時流，唯一的限制是資金有限；）我還是不明白 150 位工程師在這方面做了什么... 很抱歉，我目前沒有客戶，流量非常大。 150 名工程師可以同時建立 10 個創業公司！ 沒有留下深刻印象。 我不知道為什么 Google 網站管理員工具 Dobes 會顯示該網站存在我什至無法在該網站上找到的問題，但是卻沒有說出它是否帶有惡意軟件。 我不知道 Facebook 工程師的自我來自何處。 毫無疑問，這是一個很難解決的問題，但我認為這與核武器的復雜性不相上下。 Facebook live 的問題都不是新問題。 它們是成熟的技術，許多公司已經多次解決了它們。 規模仍然非常可觀，我想你們應該專注于此。 我對 MPEG-DASH 感到擔心，“它允許自適應比特率。編碼質量可以根據網絡吞吐量而變化”。 那是優點還是缺點？ 謝謝。 自適應比特率通常被認為是一個優勢，因為只要帶寬高于最小比特率，流就不會中斷。 順便說一下，就我所知，MPEG-DASH 與 HLS 本質上相同，都允許自適應比特率。