Facebook如何實現(xiàn)80萬人同時在線觀看直播
現(xiàn)在只有極少數(shù)公司知道如何提供世界跨越式分布服務,這些公司的數(shù)量甚至比當今擁有核武器的國家還少。Facebook就是這少數(shù)中的一個,它的新視頻直播流媒體產(chǎn)品Facebook Live就是跨越式分布服務的代表。
Facebook CEO 馬克·扎克伯格:
我們最終決定將視頻服務的重心轉向直播,因為直播是一種新興的模式,不同于過去五到十年的網(wǎng)絡視頻模式,我們即將進入視頻發(fā)展的黃金階段。如果時間快進五年,人們在Facebook上看到的大部分內(nèi)容都可能會以視頻的形式呈現(xiàn)。
Facebook直播的強大技術體現(xiàn)在一段45分鐘的視頻中,視頻里兩人用橡皮筋給西瓜施壓最后使其爆炸。這段視頻最大觀看人數(shù)高達80萬,并有超過30萬條評論。這一驚人數(shù)據(jù)是基于Facebook15億用戶基礎上的。
2015年美國超級碗播出時,有11.4億人觀看了比賽,約236萬通過直播觀看比賽。在Twitch平臺上,2015年E3游戲盛會中最高觀看人數(shù)達到84萬。在9月13日共和黨辯論時,直播觀看人數(shù)一度達到92.1萬。
在當前科技條件下,在直播領域,F(xiàn)acebook也是遙遙領先的。不容忽視的是,F(xiàn)acebook同時在進行著很多直播節(jié)目。
Facebook產(chǎn)品總監(jiān)Chris Cox:
Wired中一篇文章援引Facebook產(chǎn)品總監(jiān)Chris Cox的話,稱Facebook有超過100人的部門在負責直播(一開始只有不到12人,現(xiàn)在已經(jīng)發(fā)展到擁有150個工程師)。
Facebook需要為數(shù)百萬個同時進行的直播提供服務而不出現(xiàn)故障,同時還要為觀看直播的數(shù)百萬個觀眾提供支持,而且還要處理不同設備和服務商之間流暢連接的問題。Cox說“這確實是個很棘手的技術問題,需要強大的基礎設施。”
大家是不是很好奇這些基礎設施的問題是如何解決的呢?
Facebook流量團隊的Federico Larumbe一直在研究一個超高速緩存軟件,可以為Facebook內(nèi)容分發(fā)網(wǎng)絡和全球負載均衡系統(tǒng)提供動力,他做了一個精彩的演講。演講中他詳細介紹了直播是如何實現(xiàn)的。這篇演講確實非常精彩。
直播技術的起點
Facebook有一項新功能,就是允許用戶實時分享錄像視頻。直播服務開始于2015年4月,起初只有名人才能通過Mentions應用享受這一服務,主要用于與他們的粉絲互動。隨后一年,這項服務產(chǎn)品得到了提升,產(chǎn)品協(xié)議也發(fā)生變化。他們開始借助流媒體和超文本傳輸直播,并得到了iPhone的支持,允許他們使用CDN結構。與此同時,F(xiàn)acebook開始研究基于傳輸控制協(xié)議的實時消息傳送協(xié)議(RTMP,Real-Time Messaging Protacol),可以從手機傳送一條視頻直播或音頻直播至直播服務器。
優(yōu)點:對于那些主播與看客來說,RTMP具有更低的風險。與傳統(tǒng)播放方式不同,人們在直播平臺上可以互相交流溝通。低風險低延遲,用戶體驗就得以提升。
缺點:因為原設備不是基于超文本傳輸協(xié)議的,所以需要一整套新的結構。新的實時消息傳送協(xié)議需要經(jīng)過一段時間發(fā)展才能形成規(guī)模。
Facebook同時還研究MPEG-DAH (HTTP的動態(tài)自適應流媒體)
優(yōu)點:和流媒體相比,它能節(jié)省15%的空間。
缺點:它對比特率要求較靈活。根據(jù)網(wǎng)絡吞吐量的不同,編碼質(zhì)量也會出現(xiàn)差別。
直播的視頻是多種多樣的,而此引發(fā)的問題
直播會經(jīng)歷西瓜式的流量模式:開始后會經(jīng)過一個急劇上升的過程,幾分鐘以后,每秒就有超過100條請求,并且持續(xù)增長,直至直播結束,之后流量會急劇下降,換句話說,流量變化是非常劇烈的。
直播和一般的視頻節(jié)目不同,它會產(chǎn)生十分極端的流量模式。直播節(jié)目更能吸引人們的注意,因此通常觀看人數(shù)是普通視頻的3倍還多。動態(tài)消息中排在靠前位置的直播通常會有更多人觀看,而且關于直播的通知會通過每個頁面發(fā)給所有粉絲,這樣一來,觀看視頻的人數(shù)就會更多。 然而極端的流量會導致超高速緩存系統(tǒng)和全球負載平衡系統(tǒng)方面出現(xiàn)問題:
超高速緩存問題
在同一時間有很多人都可能想看直播視頻。這是經(jīng)典的驚群效應問題。極端流量模式對超高速緩存系統(tǒng)施加了非常大的壓力。視頻被分解成一秒一秒的文件,當極端流量出現(xiàn)時,緩存這些文件的服務器就會出現(xiàn)超負荷問題。
全球負載均衡問題
Facebook在世界各地都有入網(wǎng)點,流量分布在世界各個國家。所以Facebook需要解決的問題是如何防止入網(wǎng)點超負荷。
整體架構
直播內(nèi)容是如何傳送到數(shù)百萬觀眾那里的呢?主播在他們的手機中開始視頻直播。手機將一個RTMP流視頻發(fā)至直播服務器。服務器解碼視頻,然后轉碼成多種比特率。接著,每一種比特率都產(chǎn)生一組一秒的MPEG-DASH片段。這些片段儲存在數(shù)據(jù)緩存處理中心,然后發(fā)送到入網(wǎng)點的緩存硬盤中。觀眾端就可以收到直播節(jié)目,他們設備里的播放器以每秒一個的速度從入網(wǎng)點緩存中提取片段。
運作的原理是什么?
在數(shù)據(jù)緩存中心和眾多入網(wǎng)點緩存之間,存在一種乘法關系。用戶進入的是入網(wǎng)點緩存而非數(shù)據(jù)中心,這些入網(wǎng)點緩存是分布在世界各地的。
另一種乘法關系是在入網(wǎng)點內(nèi)發(fā)生的。入網(wǎng)點有兩個層面:代理服務器層面和緩存層面。觀眾從代理服務器中發(fā)出提取片段的請求。服務器檢查緩存中是否存在片段。如果有存在,片段就會發(fā)送給觀眾,如果沒有,這個請求就被發(fā)送至數(shù)據(jù)中心。不同的片段存放在不同的緩存硬盤中,這樣一來,不同的緩存主機之間就能達到負荷均衡。
在驚群效應下保護數(shù)據(jù)中心
如果所有的觀眾都在同一時間要求提取同一片段,會出現(xiàn)什么情況呢?如果該片段不在緩存中,每個觀眾的請求都會被送往數(shù)據(jù)中心,所以需要對數(shù)據(jù)中心進行保護。
請求合并
通過將請求合并到入網(wǎng)點緩存中,請求的數(shù)量就會減少。只有第一個發(fā)出的請求會發(fā)往數(shù)據(jù)中心。其他的請求暫時不處理,直到第一個請求得到回復,然后數(shù)據(jù)就會發(fā)往各個觀眾手里?,F(xiàn)在代理服務器中又增加了緩存層,以防止出現(xiàn)熱服務器問題。如果所有有關的請求都被發(fā)往一個緩存主機,等待片段發(fā)回,這樣就可能會使主機超負荷。
全球負載均衡解決方案
雖然數(shù)據(jù)中心得到了很好的保護,防止出現(xiàn)驚群效應問題,但是入網(wǎng)點依然存在風險。直播流量可能太過巨大,以至于在入網(wǎng)點的負載檢測到達平衡之前就出現(xiàn)超負荷的情況。
每個入網(wǎng)點的服務器和連通性是有限的。如何能夠防止入網(wǎng)點出現(xiàn)超負荷的情況呢?一個名為Cartographer maps的系統(tǒng)可以很好地解決這一問題。它能測量每個網(wǎng)絡和入網(wǎng)點的延遲,即時延測量。每個用戶都被送往最近的入網(wǎng)點,每個入網(wǎng)點的負載都可以得到測量。在服務器中有計數(shù)器來測量他們接受的負荷大小。這些計數(shù)器的數(shù)據(jù)匯集起來之后,我們就知道每個入網(wǎng)點的負荷了。
容量約束和減小風險的最優(yōu)化問題
因為控制系統(tǒng)的關系,在測量和行動時會出現(xiàn)延遲。他們將負荷測量窗口從90秒改到3秒。這個問題的解決方案就是一定要在負荷發(fā)生前就預測出來。將一個容量估量器安置到其中,通過之前的負荷和當前負荷推斷出每個入網(wǎng)點的未來負荷。
估量器是如何預計負荷?如果當前負荷增長,它有下降的可能嗎?
三次樣條函數(shù)比線性插值函數(shù)能預測更多復雜的流量模式,我們運用三次樣條函數(shù)解決插值函數(shù),先得出一階導數(shù)和二階導數(shù)。如果速度為正,負荷就上漲。如果加速度為負,意味著速度減小,最后減小為零。
避免震蕩
插值函數(shù)還可以解決震蕩問題。
測量和反應的延遲是因為數(shù)據(jù)過期,插值函數(shù)可以減少失誤,進行更準確預測,并且減少震蕩。如此一來,負荷就會更加接近容量目標。目前的預測是基于最后的三個間隔,每個間隔30秒,幾乎瞬間就超載了。
作者:燈塔大數(shù)據(jù)
原文地址:http://www.36dsj.com/archives/56173
本文來源于人人都是產(chǎn)品經(jīng)理合作媒體@站長之家,作者@燈塔大數(shù)據(jù)
讓我想起斗魚tv14億人在線觀看 這樣的公司全球也就一家