Facebook如何實(shí)現(xiàn)80萬人同時(shí)在線觀看直播？

現(xiàn)在只有極少數(shù)公司知道如何提供世界跨越式分布服務(wù)，這些公司的數(shù)量甚至比當(dāng)今擁有核武器的國(guó)家還少。Facebook就是這少數(shù)中的一個(gè)，它的新視頻直播流媒體產(chǎn)品Facebook Live就是跨越式分布服務(wù)的代表。

我們最終決定將視頻服務(wù)的重心轉(zhuǎn)向直播，因?yàn)橹辈ナ且环N新興的模式，不同于過去五到十年的網(wǎng)絡(luò)視頻模式，我們即將進(jìn)入視頻發(fā)展的黃金階段。如果時(shí)間快進(jìn)五年，人們?cè)贔acebook上看到的大部分內(nèi)容都可能會(huì)以視頻的形式呈現(xiàn)。

Facebook直播的強(qiáng)大技術(shù)體現(xiàn)在一段45分鐘的視頻中，視頻里兩人用橡皮筋給西瓜施壓最后使其爆炸。這段視頻最大觀看人數(shù)高達(dá)80萬，并有超過30萬條評(píng)論。這一驚人數(shù)據(jù)是基于Facebook15億用戶基礎(chǔ)上的。

2015年美國(guó)超級(jí)碗播出時(shí)，有11.4億人觀看了比賽，約236萬通過直播觀看比賽。在Twitch平臺(tái)上，2015年E3游戲盛會(huì)中最高觀看人數(shù)達(dá)到84萬。在9月13日共和黨辯論時(shí)，直播觀看人數(shù)一度達(dá)到92.1萬。

在當(dāng)前科技條件下，在直播領(lǐng)域，F(xiàn)acebook也是遙遙領(lǐng)先的。不容忽視的是，F(xiàn)acebook同時(shí)在進(jìn)行著很多直播節(jié)目。

Wired中一篇文章援引Facebook產(chǎn)品總監(jiān)Chris Cox的話，稱Facebook有超過100人的部門在負(fù)責(zé)直播(一開始只有不到12人，現(xiàn)在已經(jīng)發(fā)展到擁有150個(gè)工程師)。

Facebook需要為數(shù)百萬個(gè)同時(shí)進(jìn)行的直播提供服務(wù)而不出現(xiàn)故障，同時(shí)還要為觀看直播的數(shù)百萬個(gè)觀眾提供支持，而且還要處理不同設(shè)備和服務(wù)商之間流暢連接的問題。Cox說“這確實(shí)是個(gè)很棘手的技術(shù)問題，需要強(qiáng)大的基礎(chǔ)設(shè)施?！?/p>

大家是不是很好奇這些基礎(chǔ)設(shè)施的問題是如何解決的呢?

Facebook流量團(tuán)隊(duì)的Federico Larumbe一直在研究一個(gè)超高速緩存軟件，可以為Facebook內(nèi)容分發(fā)網(wǎng)絡(luò)和全球負(fù)載均衡系統(tǒng)提供動(dòng)力，他做了一個(gè)精彩的演講。演講中他詳細(xì)介紹了直播是如何實(shí)現(xiàn)的。這篇演講確實(shí)非常精彩。

Facebook有一項(xiàng)新功能，就是允許用戶實(shí)時(shí)分享錄像視頻。直播服務(wù)開始于2015年4月，起初只有名人才能通過Mentions應(yīng)用享受這一 服務(wù)，主要用于與他們的粉絲互動(dòng)。隨后一年，這項(xiàng)服務(wù)產(chǎn)品得到了提升，產(chǎn)品協(xié)議也發(fā)生變化。他們開始借助流媒體和超文本傳輸直播，并得到了iPhone的 支持，允許他們使用CDN結(jié)構(gòu)。與此同時(shí)，F(xiàn)acebook開始研究基于傳輸控制協(xié)議的實(shí)時(shí)消息傳送協(xié)議(RTMP，Real-Time Messaging Protacol)，可以從手機(jī)傳送一條視頻直播或音頻直播至直播服務(wù)器。

優(yōu)點(diǎn)：對(duì)于那些主播與看客來說，RTMP具有更低的風(fēng)險(xiǎn)。與傳統(tǒng)播放方式不同，人們?cè)谥辈テ脚_(tái)上可以互相交流溝通。低風(fēng)險(xiǎn)低延遲，用戶體驗(yàn)就得以提升。

缺點(diǎn)：因?yàn)樵O(shè)備不是基于超文本傳輸協(xié)議的，所以需要一整套新的結(jié)構(gòu)。新的實(shí)時(shí)消息傳送協(xié)議需要經(jīng)過一段時(shí)間發(fā)展才能形成規(guī)模。

Facebook同時(shí)還研究MPEG-DAH (HTTP的動(dòng)態(tài)自適應(yīng)流媒體)

優(yōu)點(diǎn)：和流媒體相比，它能節(jié)省15%的空間。

缺點(diǎn)：它對(duì)比特率要求較靈活。根據(jù)網(wǎng)絡(luò)吞吐量的不同，編碼質(zhì)量也會(huì)出現(xiàn)差別。

直播會(huì)經(jīng)歷西瓜式的流量模式:開始后會(huì)經(jīng)過一個(gè)急劇上升的過程，幾分鐘以后，每秒就有超過100條請(qǐng)求，并且持續(xù)增長(zhǎng)，直至直播結(jié)束，之后流量會(huì)急劇下降，換句話說，流量變化是非常劇烈的。

直播和一般的視頻節(jié)目不同，它會(huì)產(chǎn)生十分極端的流量模式。直播節(jié)目更能吸引人們的注意，因此通常觀看人數(shù)是普通視頻的3倍還多。動(dòng)態(tài)消息中排在靠前 位置的直播通常會(huì)有更多人觀看，而且關(guān)于直播的通知會(huì)通過每個(gè)頁(yè)面發(fā)給所有粉絲，這樣一來，觀看視頻的人數(shù)就會(huì)更多。 然而極端的流量會(huì)導(dǎo)致超高速緩存系統(tǒng)和全球負(fù)載平衡系統(tǒng)方面出現(xiàn)問題:

超高速緩存問題

在同一時(shí)間有很多人都可能想看直播視頻。這是經(jīng)典的驚群效應(yīng)問題。極端流量模式對(duì)超高速緩存系統(tǒng)施加了非常大的壓力。視頻被分解成一秒一秒的文件，當(dāng)極端流量出現(xiàn)時(shí)，緩存這些文件的服務(wù)器就會(huì)出現(xiàn)超負(fù)荷問題。

全球負(fù)載均衡問題

Facebook在世界各地都有入網(wǎng)點(diǎn)，流量分布在世界各個(gè)國(guó)家。所以Facebook需要解決的問題是如何防止入網(wǎng)點(diǎn)超負(fù)荷。

整體架構(gòu)

直播內(nèi)容是如何傳送到數(shù)百萬觀眾那里的呢?主播在他們的手機(jī)中開始視頻直播。手機(jī)將一個(gè)RTMP流視頻發(fā)至直播服務(wù)器。服務(wù)器解碼視頻，然后轉(zhuǎn)碼成 多種比特率。接著，每一種比特率都產(chǎn)生一組一秒的MPEG-DASH片段。這些片段儲(chǔ)存在數(shù)據(jù)緩存處理中心，然后發(fā)送到入網(wǎng)點(diǎn)的緩存硬盤中。觀眾端就可以 收到直播節(jié)目，他們?cè)O(shè)備里的播放器以每秒一個(gè)的速度從入網(wǎng)點(diǎn)緩存中提取片段。

運(yùn)作的原理是什么?

在數(shù)據(jù)緩存中心和眾多入網(wǎng)點(diǎn)緩存之間，存在一種乘法關(guān)系。用戶進(jìn)入的是入網(wǎng)點(diǎn)緩存而非數(shù)據(jù)中心，這些入網(wǎng)點(diǎn)緩存是分布在世界各地的。

另一種乘法關(guān)系是在入網(wǎng)點(diǎn)內(nèi)發(fā)生的。入網(wǎng)點(diǎn)有兩個(gè)層面：代理服務(wù)器層面和緩存層面。觀眾從代理服務(wù)器中發(fā)出提取片段的請(qǐng)求。服務(wù)器檢查緩存中是否存 在片段。如果有存在，片段就會(huì)發(fā)送給觀眾，如果沒有，這個(gè)請(qǐng)求就被發(fā)送至數(shù)據(jù)中心。不同的片段存放在不同的緩存硬盤中，這樣一來，不同的緩存主機(jī)之間就能 達(dá)到負(fù)荷均衡。

在驚群效應(yīng)下保護(hù)數(shù)據(jù)中心

如果所有的觀眾都在同一時(shí)間要求提取同一片段，會(huì)出現(xiàn)什么情況呢?如果該片段不在緩存中，每個(gè)觀眾的請(qǐng)求都會(huì)被送往數(shù)據(jù)中心，所以需要對(duì)數(shù)據(jù)中心進(jìn)行保護(hù)。

請(qǐng)求合并

通過將請(qǐng)求合并到入網(wǎng)點(diǎn)緩存中，請(qǐng)求的數(shù)量就會(huì)減少。只有第一個(gè)發(fā)出的請(qǐng)求會(huì)發(fā)往數(shù)據(jù)中心。其他的請(qǐng)求暫時(shí)不處理，直到第一個(gè)請(qǐng)求得到回復(fù)，然后數(shù) 據(jù)就會(huì)發(fā)往各個(gè)觀眾手里。現(xiàn)在代理服務(wù)器中又增加了緩存層，以防止出現(xiàn)熱服務(wù)器問題。如果所有有關(guān)的請(qǐng)求都被發(fā)往一個(gè)緩存主機(jī)，等待片段發(fā)回，這樣就可能 會(huì)使主機(jī)超負(fù)荷。

全球負(fù)載均衡解決方案

雖然數(shù)據(jù)中心得到了很好的保護(hù)，防止出現(xiàn)驚群效應(yīng)問題，但是入網(wǎng)點(diǎn)依然存在風(fēng)險(xiǎn)。直播流量可能太過巨大，以至于在入網(wǎng)點(diǎn)的負(fù)載檢測(cè)到達(dá)平衡之前就出現(xiàn)超負(fù)荷的情況。

每個(gè)入網(wǎng)點(diǎn)的服務(wù)器和連通性是有限的。如何能夠防止入網(wǎng)點(diǎn)出現(xiàn)超負(fù)荷的情況呢?一個(gè)名為Cartographer maps的系統(tǒng)可以很好地解決這一問題。它能測(cè)量每個(gè)網(wǎng)絡(luò)和入網(wǎng)點(diǎn)的延遲，即時(shí)延測(cè)量。每個(gè)用戶都被送往最近的入網(wǎng)點(diǎn)，每個(gè)入網(wǎng)點(diǎn)的負(fù)載都可以得到測(cè)量。 在服務(wù)器中有計(jì)數(shù)器來測(cè)量他們接受的負(fù)荷大小。這些計(jì)數(shù)器的數(shù)據(jù)匯集起來之后，我們就知道每個(gè)入網(wǎng)點(diǎn)的負(fù)荷了。

容量約束和減小風(fēng)險(xiǎn)的最優(yōu)化問題

因?yàn)榭刂葡到y(tǒng)的關(guān)系，在測(cè)量和行動(dòng)時(shí)會(huì)出現(xiàn)延遲。他們將負(fù)荷測(cè)量窗口從90秒改到3秒。這個(gè)問題的解決方案就是一定要在負(fù)荷發(fā)生前就預(yù)測(cè)出來。將一個(gè)容量估量器安置到其中，通過之前的負(fù)荷和當(dāng)前負(fù)荷推斷出每個(gè)入網(wǎng)點(diǎn)的未來負(fù)荷。

估量器是如何預(yù)計(jì)負(fù)荷?如果當(dāng)前負(fù)荷增長(zhǎng)，它有下降的可能嗎?

三次樣條函數(shù)比線性插值函數(shù)能預(yù)測(cè)更多復(fù)雜的流量模式，我們運(yùn)用三次樣條函數(shù)解決插值函數(shù)，先得出一階導(dǎo)數(shù)和二階導(dǎo)數(shù)。如果速度為正，負(fù)荷就上漲。如果加速度為負(fù)，意味著速度減小，最后減小為零。

避免震蕩

插值函數(shù)還可以解決震蕩問題。

測(cè)量和反應(yīng)的延遲是因?yàn)閿?shù)據(jù)過期，插值函數(shù)可以減少失誤，進(jìn)行更準(zhǔn)確預(yù)測(cè)，并且減少震蕩。如此一來，負(fù)荷就會(huì)更加接近容量目標(biāo)。目前的預(yù)測(cè)是基于最后的三個(gè)間隔，每個(gè)間隔30秒，幾乎瞬間就超載了。