Facebook Live的高可用架構

FacebookLive是Facebook的視頻直播產品，這個產品開始試水時只向名人大V開放，讓他們可以通過直播和粉絲互動；對公眾開放以後，並發訪問量極大，一個熱門的直播可能有上百萬的人同時在線觀看。應對這樣多的並發訪問，還要保證視頻低延遲，是一個很難以解決的架構問題。

來自Facebook流量團隊的Federico Laramie在Networking@Scale會議上分享了Facebook Live的緩存以及負載均衡系統的設計：

Facebook Live 在2015年4月上線，只向名人開放，之後的一年產品不斷演進，技術團隊從10人擴張到150人。在2015年底，向多個國家的用戶同時開放。

協議選型

在協議層面上，他們一開始選用了HLS（HTTP Live Streaming），iPhone對於這個協議有很好的支持，而且由於它是基於HTTP，可以利用現有的CDN架構。同時，他們也開始調研RTMP協議（基於TCP），它在手機和伺服器之間建立一個視頻流和一個音頻流。RTMP的好處在於從發布者到觀眾端到端的延遲較小，延遲在支持交互的直播中對用戶體驗影響很大；但是缺點在於協議不是HTTP的，因此需要開發RTMP的代理服務，以方便擴展。同時調研的還有MPEG－DASH協議，相對於HLS，它更加節省空間。

直播的技術挑戰

直播的流量和其他互聯網產品相比有其獨特之處，見下圖：

直播開始時，並發訪問量有一個陡峭的上升，然後繼續攀升，直到直播結束，訪問量直線下降。也就是說訪問量上升極快。此外，很多產品的因素導致直播的觀看量比普通視頻要大很多，一般要3倍以上。

瞬間增加的訪問會給緩存系統和負載均衡系統帶來很多問題。

• 緩存的問題
  n相信大家都聽過Thundering Herd問題，在緩存失效的時候，大量的訪問意味著大量的回源請求，導致數據源處的請求大量堆積。

  n視頻是分割成一秒鐘的片段文件傳輸給用戶的，緩存系統會緩存這些片段，但是當訪問量過大的時候，緩存也會過載。

• 負載均衡的問題
  nFacebook有很多PoP伺服器遍布世界各地（邊緣伺服器），用於分發Facebook在全世界各處的流量。在流量過大的時候，PoP伺服器都有可能過載。

整體架構

直播流從播主到觀眾的過程是這樣的：

1. 播主在手機上啟動直播
2. 手機向直播伺服器建立一個RTMP的音頻視頻流
3. 直播流伺服器解碼這個視頻，並轉換成多種不同碼率
4. 對於每一種碼率，持續生產一秒鐘的MPEGDASH片段
5. 這些1秒鐘的片段存儲在數據中心的緩存中
6. 數據中心的緩存把片段發給多個PoP伺服器的緩存
7. 用戶看到直播信息，開始收看
8. 用戶手機開始從PoP服務不斷獲取1秒鐘的片段播放

怎樣擴展？

在這樣大的並發流量面前，必須引入多層次的緩存和負載均衡。在數據中心的緩存和多個PoP緩存之間有一個流量放大（multiplication），在每個PoP節點上，還有另一層流量放大：PoP包含兩個層次，一層HTTP代理和一層緩存。觀眾是從HTTP代理處獲取片段的，代理層檢查片段是否在PoP的緩存中，如果在，直接返回；如果不在，向數據中心緩存發送請求。因為不同的片段可能存放於不同的緩存中，這有助於在緩存層次均衡負載。

如果很多觀眾同時請求同樣一個片段，而這個片段不在PoP緩存中，就會導致有很多請求（每個用戶一個請求）發往數據中心的緩存，造成Thundering Herd問題。解決的方案是引入請求合併(Request Coalescing)，即只把第一個請求發往數據中心，其他請求在PoP排隊等待第一個請求的響應，然後數據被回復給所有請求者。

即使如此，所有的觀眾都在一個PoP的cache服務等待，也會造成這個服務的過載。所以在代理層次又增加了一個本地的緩存，同樣使用了請求合併的技巧，讓代理本身直接擋住了大量的請求。

即使有了上面的措施，PoP還存在過載的風險。因為直播流量上升極快，PoP的負載還來不及通知到負載均衡系統的時候，就可能出現過載。這時只能依靠全球的負載均衡系統Cartographer。

Cartographer這個系統把全球的子網映射到PoP，它會度量各個子網和PoP之間的延遲，同時也會度量各個PoP的負載情況（每個代理節點上有請求的計數器，一個PoP所有代理節點的計數器求和就是這個PoP的負載）。用這兩項數據，Cartographer面對的就是一個最優化問題：在保證PoP不超過負載的前提下，最小化用戶請求的延遲。

因為直播流量會急速上升，這個控制系統的度量和反應時間也要極快，為此，他們把Cartographer的度量時間窗從1.5分鐘縮小到3秒鐘，但是, 3秒的時間PoP仍然有過載威脅。怎麼辦？只能在流量到來之前想辦法預測。

他們用三次樣條曲線實現了一個流量的預測程序，通過對於前面的負載和當前的負載擬合出未來流量的走勢。這樣，即使當前流量處於上升態勢，也能預測未來流量的下降：對曲線取一階和二階導數，如果速率為正，但是加速度為負，就說明上升速率在減小，最終會變成0，這就是負載下降的開始。

實驗證明三次樣條比線性插值可以預測更為複雜的流量情況。而且對於抖動的容忍性更高。

怎樣測試？

前面講到如何防止PoP過載，但是測試的目的是，如何使PoP過載？

他們研發了一個壓力測試服務，部署在全球的所有PoP上，模擬真實的用戶流量，最高可以製造生產環境10倍以上的流量壓力。這個測試系統幫助團隊發現和解決了流量預測程序的bug，也驗證了幾個緩存層次對於Thundering Herd的承受能力。

上傳穩定性問題

上傳穩定性也是一個棘手的問題。因為用戶的上傳帶寬是有限的，音頻需要64Kbps的帶寬，而標準解析度視頻需要500Kbps。

解決問題的方法就是適應性地調整編碼，手機應用根據當前的可用帶寬動態調整視頻的比特率，而當前帶寬的估算是由過去多個時段RTMP連接上的上傳速率加權平均算得。

參考

https://www.facebook.com/atscaleevents/videos/1732398473699916/

http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf

How Facebook Live Streams to 800,000 Simultaneous Viewers - High Scalability -

P.S. 歡迎關注我的公眾號codergroup，定期推送有價值的技術文章。n

推薦閱讀：