[譯] Facebook Live如何支持80w用戶同時在線

---

寫在前面：

這又是一篇翻譯了好久的文章--花費時長其實並不久，主要是斷斷續續翻譯先後算起來時長好久。這篇大概是目前翻譯得最有共鳴的一篇文章-- 我大沙發廠也有live產品了呢。雖然量級不可比，文中提到的80w在線的流量盛況目前來講也是個遙遠的KPI,不過確實在產品迭代中也像文中同樣踩了不少坑。做爲產品在和講師溝通配置的過程當中，對文末最後提的上傳速度那一塊的效果體驗尤爲感同身受。以及，依託於第三方服務來構建本身的產品終歸須要不斷試錯和磨合--和戀愛同樣。

最近還有一個關於live而產生共鳴的地方，想來也能夠推薦一下，美劇《硅谷》。是的就是文中提到的那個魔笛手Pied Piper。具體點就是第二季大概最後幾集裏，在公司大概要宣佈破產的時候，互懟基友Gilfoyle和Dinesh還有Jared爲了撐住因 拆解禿鷹孵化的攝像頭而失足墜落的工做人員的求救直播引來的兇猛流量致使已達極限的服務器 而不停敲代碼甚至不顧它已經燒起來的盛況（這句話好長啊，不知道說沒說清楚）。雖然情節爲了劇情效果頗多不現實，但在我看來確實表明了一些geek精神還有創業維艱的事實。

---

原文地址 How Facebook Live Streams To 800,000 Simultaneous Viewers

---

譯文部分：

懂得建立世界級服務產品的公司就像掌握核武器的國家同樣很是少，Facebook就是其中之一。 而Facebook Live, 一款Facebook 新出的直播視頻推流產品，就是這些世界級服務之一。

Facebook CEO 馬克扎克伯格：

咱們作的這項重大的決定就是爲了將咱們作的大量視頻方向的嘗試更多地轉移到直播方向，由於直播是近來興起的一種新模式；而不是已經在過去五年甚至十年都存在於網絡中的視頻…咱們已經進入了視頻行業的黃金時代。若是你展望五年後的facebook,發現人們都經過直播來分享每日見聞，我一點也不奇怪。

若是你身處廣告業務，想來最使人愉悅的就是永遠不會中止的廣告來源，而且不斷擴張大量生成了吧。這就是Google 盈利的主要方式：在呈幾何級增加的網頁中插入廣告。

Facebook Live 能展示如上述的能力體現之一就是一個45分鐘的視頻：兩我的用橡皮筋切西瓜。達到了超過80萬人同時在線的頂峯，有超過30萬的評論。這就是一個擁有十億五千萬用戶的社交網絡能創造的病毒式傳播效應。

做爲對比，2015年超級碗一共有1.14億的觀衆，有大概兩百多萬的用戶觀看直播 。 在2015年的電子娛樂展的 Twith 直播中，達到了84萬的觀看量。9月16號的共和黨辯論達到了最高92.1萬的同時在線觀看人數。

因此對比來看，Facebook作直播最適合不過。須要注意的是，Facebook也可能會出現同一時段有大量直播正在進行的狀況。

連線雜誌有一篇文章引用了Facebook的首席產品負責人Chris Cox 的話：

• 有超過100人的直播產品團隊（一開始只有12人左右，如今有超過150位工程師參與該項目）

• 須要支持百萬以上的同步直播流而不崩潰

• 須要支持超過百萬的在線觀看人數，同時也要考慮全世界上不一樣的設備適配以及服務商要求

Cox 說「最後發現這是個考驗基礎架構的難題」。

若是咱們能說一說怎麼解決這個架構問題的細節，聽起來不是頗有趣嗎？ (爲了解決這個問題)咱們真的很痛苦!但等等，咱們能夠聊一下~

來自Facebook 流量團隊（traffic team）的Federico Larumbe ，主要優化 Facebook 的CDN 處理能力 以及全球加載平衡系統，發表了一次精彩的演講：Facebook Live 的演變和優化。 演講中他分享了一些關於直播如何實現的細節。

如下是演講內容的介紹。很是使人印象深入。

最開始

• Facebook 是一個容許用戶實時分享內容的新功能（注意這裏應該是指Facebook Live）

• 2015年4月以 Mentions 的移動客戶端形式發佈，當時只能名人使用，做爲和粉絲交流互動的媒介

• 由此開始了一年的產品優化以及協議迭代

  • 他們最開始使用HLS(HTTP Live Streaming) ，這個協議在iPhone設備下被支持，同時也容許他們使用存在的CDN 架構

  • 同時也開始研究 RTMP（實時消息傳輸協議），一個基於TCP 的協議。會有一個視頻流和音頻流從手機上傳到直播推流服務器

    • 優勢： RTMP 在推流端和播放端之間有更低的點到點等待時間 。這在主播和觀衆常常互動的場景下很是有用。下降等待時間以及較少的延遲在體驗上都是很是棒的改進

    • 缺點： 會請求整個架構資源由於它不是基於HTTP 協議。因而須要開發一個全新的 RTMP 代理。

  • 也在研究 MPEG-DASH (基於 HTTP 的動態適應串流）

    • 優勢：對比HLS 節省了15%的空間

    • 缺點：容許自適應比率串流 ，編碼質量會根據網絡上傳速度不斷變化

  • 魔笛手數據壓縮方法（開玩笑233333）

• 2015年12月在超過12個國家發佈

視頻直播有些不同—也形成了一堆問題

• 以前提到的橡皮筋切西瓜的直播的網絡傳輸問題：

  • 一個陡增，幾分鐘內就達到了每秒超過100次請求並且持續增長直到直播結束

  • 傳輸又像碰到障礙同樣一下徹底停下來

  • 換言之，整個數據訪問很是迅速而又猛烈

  

• 視頻直播和正常的錄製視頻不同：訪問會形成大量的網絡請求

  • 視頻直播更強調參與性所以可能有三倍於錄製視頻的訪問量

  • 視頻直播會出如今新聞動態推送的頂部所以有更大的可能性被訪問

  • 通知會被推送到全部頁面上的粉絲，所以會有另一羣用戶會觀看直播

• 迅速而又猛烈的網絡訪問請求會形成緩存和加載平衡系統方面的問題

• 緩存問題

  • 不少用戶可能想同時觀看直播視頻，這就是經典的 驚羣現象

  • 高訪問請求會給緩存系統形成壓力

  • 視頻都是被分段放進一個二級文件中，高且頻繁的訪問會讓緩存這些視頻片斷的服務器過載

• 全球加載平衡問題

• Facebook 有遍及全球的網絡鏈接點（PoPs),因此直播的網絡傳輸問題也是分佈在全球的

• 問題就在於防止高訪問量對網絡鏈接點的訪問過載問題

直播架構構建

如下就是一條直播推流如何由發起人（推流端）傳到百萬觀衆面前的過程：

• 發起人在手機上開啓視頻直播

• 手機發送一條RTMP 流到直播流服務器

• 直播流服務器解碼傳過來的視頻並轉碼成多個比特率

• 每一個比特率的信息都會建立一個二級 MPEG-DASH 片斷

• 這些片斷都被存在一個數據中心緩存器中

• 在數據中心緩存器裏，每一個片斷又會被送到網絡鏈接點中的緩存器裏（一個 PoP 緩存）

• 在播放端，觀衆就收到了一個完整的直播視頻

• 觀衆設備上的播放器會從 PoP 緩存中以每秒一次的速度抓取視頻片斷

一條直播推流又是如何傳播擴散的？

• 在數據中心緩存器和衆多 PoP 緩存器之間有一個聚合結點（multiplication point）, 用戶會向 PoP 緩存器發送請求而不是數據中心，而同時有大量的 PoP 緩存器遍及全球。

• 另外一個聚合傳播結點在每個PoP 內部

• 每個PoP 內部有兩層：一層 HTTP 協議代理層，一層緩存層

• 播放端在HTTP 代理層請求視頻片斷，代理會檢查改視頻片斷是否在緩存中，如有則直接從緩存中給出片斷，沒有則再向數據中心發送片斷請求

• 不一樣片斷被存在不一樣的緩存器中，這樣能夠減小不一樣緩存宿主之間的負載平衡

避免數據中心出現驚羣現象

• 當全部用戶同時請求了同一個視頻片斷會發生什麼？

• 若是該請求的視頻片斷不在緩存中，則會爲每個用戶向數據中心再發送一條請求

• 請求合併。請求的數量會經過向PoP 緩存添加請求合併而減小。只有第一條請求會被髮送給數據中心，其它請求則會被掛起直到第一個響應到達，數據就會被送到全部用戶播放端

• 新的緩存層會被加到代理中以免熱服務器問題

• 全部的用戶請求會被髮送到一個緩存主機中等待視頻片斷，這樣可能致使負載太重

• 代理會增長一個緩存層，只有第一條請求會被代理髮送到緩存器，全部接下來的請求則會直接被代理處理

PoPs 仍處於危險之中 —隨時須要處理全球性負載均衡問題

• 因此數據中心已被避免發生驚羣問題，可是PoP 節點仍在危險之中。直播的問題在於流量陡增太迅速PoP節點會在達到負載均衡前就已過載。

• 每個PoP節點都有一個限制服務器數量和鏈接點數量。如何避免直播時的迅猛訪問對PoP形成過載？

• 一個叫 Cartographer的系統會把子網與PoP映射起來。這個系統用來處理每一個子網和每一個PoP節點之間的延遲。這是一種延遲處理方式

• 每個PoP的加載都會被處理，每個用戶的請求都會被髮送到有足夠容量的PoP節點中。在每個代理中都有計數器來統計他們收到的加載數量。這些計數器的統計會讓咱們瞭解到每個PoP的負載狀況

• 因此又有了關於負載容量限制的考慮和最小化延遲的優化問題

• 在控制系統內部接收和處理也一樣存在延遲

• 他們將窗口的加載處理時間從一分半縮減到3秒鐘—仍存在3秒鐘延遲

• 解決問題的關鍵是預處理（上述提到的全部的須要處理的）加載時間

• 經過注入容量預估器來推斷內部加載時間以及每個PoP傳輸加載時間還有返回後的加載時間

  • 若是當前的的加載時長在上升，預測器是如何能判斷加載時間會減小？

  • 三次樣條插值函數（Cubir splines)用來描述插入函數

  • 一階導數和二階導數會先被執行，若是顯示速度爲正值則說明加載會增長。若是加速度爲負值則意味着速度在減小並最終減爲零並開始減速。

  • 三次樣條插值函數比線性函數更能預測複雜的網絡流量類型

  • 避免抖動，這類插入函數同時也避免了傳輸抖動問題

  • 接收和處理的延遲意味着在對舊數據的處理，插入函數能減小出錯，更精準預測和減小抖動，這樣能使負載更接近容量目標

  • 當前預測時間是基於最近三次處理的間隔時間（每次間隔有30秒），幾乎是瞬時加載

測試

• 須要測試PoP的過載狀況

• 一個模擬直播實時流量的加載測試服務會經過PoP節點分發到全球

• 可以模擬10倍於正常狀況下的負載

• 可以模擬一位觀衆不停請求視頻片斷的狀況

• 測試系統幫助復現和修復容量預估器會出現的問題，修正一些參數值設置，以及鑑別緩存層可能出現的驚羣現象

上傳可靠性

• 實時上傳視頻很是有挑戰性

• 以大概有100-300 Kbps 的有效帶寬爲例

• 音頻大概須要64 Kbps 的有效上傳帶寬

• 標清視頻須要大概500 Kbps

• 移動設備上採用適應性編碼來調整音頻+視頻上傳時碼率不足的問題。編碼視頻時會根據網絡上行帶寬來調整上傳碼率

• 經過處理 RTMP 協議鏈接時的上傳字節數來自動調節手機上的上傳碼率，通常是經過讀取單位上傳時間間隔內獲取的字節數的平均速率

將來的方向

• 研究推流方向的優化而非拉流，在視頻片斷被PoP節點請求前來平衡 HTTP/2 協議的推流效率

相關文章

• hacker news

• 爲何扎克伯格全力投入視頻直播方向

• 鏈接世界：facebook的網絡架構一瞥

• Gamoloco 獲取到的1476093 個頻道的視頻直播數據