【伯樂線上小編注】：此文來自合作網站 Inside 硬塞，他們是臺灣網站，所以本文中有些技術術語和大陸不一樣。

知道怎麼打造世界級分散式服務（distributed service）的公司，可能比擁有核武的國家還少。Facebook不僅是其中的佼佼者，而它新推出的直播功能就是一項分散式服務。

Facebook執行長  Mark Zuckerberg  就曾經說過：

我們做了重大決定，就是把在影片的努力轉而聚焦到直播上，因為它是接下來的新格式，而非已經存在線上5 — 10 年的那種影片。我們正進入影片的新黃金年代，我相信往前快轉5 年，很有可能Facebook 上使用者每天分享的內容幾乎都是影片。

如果你在廣告業，還有什麼比沒有盡頭、一直在成長，而且免費產生的內容更適合拿來放廣告呢？這就像Google在網路指數成長時，為各網站提供廣告所開拓的市場一樣。

Facebook的直播技術堅強，就像BuzzFeed在Facebook直播用橡皮筋爆西瓜，最高達80萬人同時在線上收看，共有30多萬條留言。這也是在15億使用者的社群網路上才看得到的病毒傳播效應。

作為參考， 2015 年的超級盃共有1.14 億觀眾收看，平均有236 萬人在看直播；2015 的E3 電玩展則同時有84 萬人在Twitch 上收看；而9 月16 日的共和黨辯論最多有92.1 萬人同時在收看直播。

與此同時， Facebook 上還有其他大量的直播正在發生。那麼Facebook 到底投注了多少資源在直播上呢？

根據Facebook的產品長Chris Cox在Wired報導上提到：

有超過百人在直播底下工作。一開始在12 人左右，到現在已經有超過150 名工程師。

要能同時處理上百萬條直播而不當機。

要能負擔一條直播上的數百萬位觀眾，還要在全球不同的裝置和網路提供商間無縫同步播出。

Cox 也承認「結果基礎架構的問題真的不好解決。」

要是我們能知道這些基礎問題是怎麼解決的，應該會很有趣。

Facebook流量團隊的  Federico Larumbe，就在Facebook技術部落格上發表了《Scaling Facebook Live》，裡面提到了直播運作的細節。

原文相當精彩，重點節錄如下：

起源

• Facebook 開了一個新功能，讓使用者能分享即時影片。（注意，在這裡直播對Facebook 來說就是一個功能而已）
• 2015 年4 月只能透過Mention app 直播，而且限定名人專用。
• 隨後便展開長達一年的改進與協定的變動。
  • 他們從HLS （HTTP Live Streaming）開始，iPhone 可支援，而且他們也可以使用現有的內容傳遞網路。
  • 同時開始研究  RTMP  (Real-Time Messaging Protocol，即時訊息傳送協定) ，這是一種基於TCP的協定。分別有一條音訊串流和視訊串流從手機傳送到直播伺服器。
    • 優點：RTMP 在直播主和觀眾間點對點的延遲較低，在互動式的直播上特別有幫助。降低延遲也能提升整體的體驗。
    • 缺點：因為不是基於HTTP，所以需要全新的架構。要規模化一定要架個新的RTMP 代理。
  • 另外也研究了  MPEG-DASH（基於HTTP的動態與適應性媒體串流）
    • 優點：比HLS 省15% 的空間。
    • 優點：自動調整傳輸率，會根據網路狀況改變傳輸品質。
• 2015 年12 月在數十個國家展開服務。

直播影片很特別，也帶來許多問題

• 拿一開始的西瓜影片流量表現為例：
  • 在一開始流量上升得很快，數分鐘內就達到每秒超過100 個請求，直到影片結束都持續上升。
  • 影片一結束流量就直直落。
  • 簡而言之：瞬間流量很大。
• 直播影片和一般影片不一樣：它會產生瞬間流量。
  • 直播影片和觀眾的連結更深，所以通常觀看次數比一般影片多3 倍。
  • 直播影片會被推到資訊牆最上方，所以被看到的機會也比較高。
  • 專頁的所有粉絲都會收到直播通知，又吸引到一批可能會來看影片的觀眾。
• 瞬間流量會對cache （暫存）系統和負載平衡系統造成問題。
• Cache 的問題
  • 很多人同時想要收看你的直播，導致經典的「驚群效應」（Thundering Herd problem），大量等待中的處理程式同時被喚醒，卻只能一次處理一項。
  • 大量瞬間流量會對cache 系統造成壓力。
  • 一部串流影片被分割成很多一秒的小檔，流量飆高時，暫存這些分割檔的伺服器可能會超載。
• 全球負載平衡系統的問題
  • Facebook 在全世界都有分佈PoP ，Facebook 的流量是分散到全世界的。
  • 所以挑戰在於避免瞬間流量灌爆其中一個PoP。

整體架構

這裡是直播如何從直播源散佈給上百萬觀眾的過程。

• 直播主從手機開了一條直播。
• 手機傳了RTMP 串流到直播伺服器。
• 直播伺服器解碼影片後轉換成各種傳輸率的影片。
• 每種傳輸率都創造一組 MPEG-DASH 的連續數個一秒鐘片段。
• 這些片段都存在資料中心的暫存裡。
• Cache 暫存從資料中心傳送到各個PoP 暫存。
• 觀眾收到直播。
• 觀眾手機上的播放器以每秒一次的頻率開始從PoP 接收片段。

要怎麼規模化？

• 從資料中心到PoP，端點數會增加非常多。使用者會存取PoP暫存而非資料中心暫存，而PoP是分佈在全世界的。
• 另外每個PoP內部還會再細分。
  • 每個PoP內部都分成兩層：一層是HTTP代理，另一層是暫存。
  • 觀眾從HTTP 代理請求片段。代理會檢查片段有沒有在暫存裡面，有的話就會回傳片段，沒有的話就會往回向資料中心請求片段。
  • 不同的片段存在不同的暫存，所以能讓不同的host負載平衡。

保護資料中心免於驚群效應

所有觀眾同時要求同一個片段會發生什麼事？

• 如果片段不在暫存裡，每個觀眾都會向資料中心發出一筆請求。
• Request Coalescing（迴應聯合）。透過在PoP暫存增加request coalescing來減少請求的數量。只有第一個請求會傳到資料中心，其他的請求會被攔下，直到第一個請求到了資料中心，然後資料回傳到所有觀眾手上。
• 代理會加上一層新的暫存，來避免伺服器過熱。
  • 所有的觀眾會被送到一臺暫存host 去等待接收，這可能會導致host 過熱。
  • 代理加了一層暫存層。只有第一個到代理的請求會成功要到暫存。其他的請求會直接由代理處理。

PoP 還是身陷險境：靠全球負載平衡來拯救

• 所以資料中心免於驚群效應的問題，但是PoP 還是暴露在危險中。問題在於，PoP 的負載衡量結果到達負載平衡器之前，流量可能就已經灌爆PoP 了。
• 每個PoP 都有限制伺服器和連線的數量。瞬間流量要如何不灌爆PoP？
• 一個叫做Cartographer 的系統會描繪網際網路到PoP 的子網路。它會衡量每個子網路和PoP 間的延遲。
• 測量每個PoP 的負載後，每位使用者就會被傳送到附近能夠負載的PoP 。代理有計數器會記錄他們收到多少負載。這些計數會累計，所以我們可以知道每個PoP 的負載。
• 現在現在出現了一個最佳化問題，我們要在負載限制下同時降低延遲。
• 用控制系統，可以分為測量的延遲和反應的延遲。
• 他們把負載測量間隔從1.5 分鐘縮短到3 秒鐘，但是這樣仍舊有3 秒鐘的空窗。
• 解決辦法是在發生之前先預測負載。
• 依據先前及當下的負載，負載估計器會預測未來的負載量。
  • 如果現在的流量是上升，預測器要怎麼才能預測到流量下降？
  • 在插入函式使用三次樣條函式（Cubic spline）。
  • 利用一階和二階導數。如果速度是正的，那負載量就會增加，如果加速度是負的，就表示速度下降，最後負載會開始降低。
  • 三次樣條函式能預測比線型函式更復雜的流量模式。
  • 避免波動。這個插入式也可以解決波動的問題。
  • 測量和反應的延遲，表示會依據不夠及時的資料做決定。插入式函式能減少錯誤，讓預測更準確，並降低波動。所以負載量能更接近目標。
  • 現在是根據過去的三個區間來做預測，每個區間間隔30 秒。幾乎是等於即時的負載量。

測試

• 首先你要能讓一個PoP 過載。
• 負載測試分散在全球的PoP 上，好模擬直播的即時流量。
• 要能模擬目前負載量的10 倍。
• 要能模擬一位一次請求一個片段的觀眾。
• 這個系統能找出並修補負載估計器的問題、調整引數，並驗證暫存層能否克服驚群效應。

上傳的穩定性

• 即時上傳影片很有挑戰性。
• 舉一個頻寬介於100 — 300 Kbps 的上傳為例。
• 音訊總共要64 Kbps。
• 標準畫質的視訊共要500 Kbps。
• 利用手機上的適應性編碼來調整音訊加視訊的不足。影片的傳輸率編碼會根據網路頻寬調整。
• 手機端會測量RTMP 上傳位元，來決定上傳的傳輸率，並且根據上個區間的平均來加權。

未來的方向

• 研究推送機制，而非request-pull 機制。在請求片段之前就利用HTTP/2 推送至PoP。