海量用戶實時互動直播架構探索

如今比較流行的直播，常常會出現這樣的狀況： 用戶打了一個彈幕上去，主播念出來的時候，彈幕已經飛出去了。兩者時間是不匹配的。

這是咱們的一個客戶，兩個主播連線互動，實時交互。試想，若是直播時延時高達幾秒，像這樣的雙主播組合是沒有辦法進行交談的。A說完以後，對方要等幾秒才能聽到，又過了幾秒，A才能聽到對方的回答。

這兩個例子其實要說明實時互動直播和普通直播相比有本質的區別：延時。實時互動直播延時必須低達幾百毫秒。

爲何是幾百毫秒？爲何不是幾秒也不是幾毫秒？這是由人們平常交流習慣決定的。人的說話聲音經過聲波傳播，若是兩人相隔34米，那麼延時就是100毫秒。基於這個範圍，略長的延時，觀衆還能。基於互聯網的音視頻通訊，音頻通話延時標準在400毫秒之內，視頻通話延時在800毫秒之內，這可讓通話雙方無延時感知的。延時若是達到秒的數量級，那麼通話雙方就會有明顯的等待。

互聯網是基於電磁波或者經過光纖傳播的。光繞地球一圈，耗時300毫秒，這是沒法逾越的物理定律延時。有人號稱能夠作到0延時，他們估計用上了量子通訊。在實際互聯網應用中，網絡條件並不理想，互聯網信號繞地球一圈的延時必然大於300毫秒。這就給實時互動直播，帶來了巨大的挑戰。

實時互動直播的挑戰

第一，互聯網的骨幹網上路由器的部署，不是直線點到點，而是中間要通過不少路由器的跳數，其實是在走「彎路」。因此，互聯網傳輸沒有辦法繞地球一圈正好300毫秒，最好的狀況也須要要近400毫秒。

第二，公共互聯網上，路由器其實常常出現故障。好比，在晚高峯的時候，網絡會比較慢。這是由於部分路由器可能過載。由於路由器有最大的處理能力上限，一旦超過上限，就不能處理，會形成丟包、擁塞。

第三，無線網絡相對有線網絡，可靠性較低。無線網絡普及度愈來愈高，，愈來愈多的手機、筆記本鏈接無線網。可是無線網絡相對有線網絡沒有那麼可靠，同時也會引入信號污染。信號覆蓋不到的地方，效果較差。

第四，高併發挑戰。首先須要普及一個概念：併發和在線是有區別的。當今的移動互聯網，你們都在講千萬級。當咱們談及海量用戶架構這個話題時，彷佛若是不說到上億這個量級，是落後了。可是實際上，前面這些說法都混淆概念了，它們都在說「在線」，而不是「併發」。如下圖爲例：

左邊是QQ在線好友列表，圖中能夠看到不少好友展示，其實沒有交互，使用者不會有壓力。右邊是一個框同時和不少人聊天，使用者會感覺到巨大壓力。一樣的，對於直播服務而已，若是用戶只是在線，不多會跟服務器有交流，最多偶爾發一個心跳包。

用戶在線時，若是參與了「看」「說」，這就是併發。直播的併發峯值具備突發性，每每跟主播的活動密切相關。好比，主播會跟粉絲約定直播時間，到了約好的時間，粉絲就會在短期大量涌入一個直播頻道。觀衆慢慢進入頻道，服務器沒有壓力，但若是瞬間涌入，後臺的壓力很是大。

本文，將重點介紹互動直播的可用性問題。電信業務的可用性標準是四個九，咱們指望作到五個九。雙十一時，支付寶的處理能力很是強，百度百科上提供的數據顯示，支付寶當天處理了96%訂單。可是，咱們對本身的互動直播有更高的要求，指望作到99.999%。

實時互動直播要保證高可用性，有巨大的難度，緣由以下：

1. 實時很難。互聯網基礎設施不是爲實時通訊設計的。

2. 覆蓋很難。機房找點，互聯互通。對通訊雲來講，覆蓋很差會影響到可用性。

3. 高併發很難。不能看着看着就不動了，沒聲了。

4. 突發性很難。系統容量要高，還要防止雪崩。

這些挑戰咱們在作整個服務的時候，都須要全面考慮。

直播架構的演進

一、CDN直播架構

這是當前流行的直播架構，左下角是一個主播，主播經過手機或電腦等設備，把本身的視頻流上傳到服務器，接入目前流行的CDN服務，經過CDN服務進行網絡分發，分發到各地的用戶。全部用戶均可以看到主播的表演。

二、單服務器實時互動直播架構

實時互動直播，不能使用CDN方案，由於CDN方案性質決定了延時達不到實時的要求。下圖是咱們認爲能夠實現實時互動的架構。主播把本身的視頻流上傳到服務器，經過這臺服務器分發給其餘用戶，再採用合適的傳輸協議，延時能夠作到很小。從主播到服務器再到觀衆的延時，加上編解碼和抖動的延時，能夠作控制在幾百毫秒之內。

這個架構很簡單，但有一個缺點，沒有考慮覆蓋不一樣地用戶的問題。而且一臺服務器支撐不了大規模用戶。這臺服務器若是宕機，或者服務器機房出故障，整個傳輸都會受到影響。這必然達不到高可用架構的標準。

三、分佈式實時互動直播架構

主播的視頻流上傳到一個接入服務器，這個服務器會把這個視頻流分發到咱們部署在世界各地的服務器。而後這些服務器接入本地的用戶，把視頻傳下去。

在這個架構裏面，首先能夠解決的是覆蓋問題，部署在世界各地的服務器，可讓用戶能夠快速就近接入。整個視頻流經過咱們在互聯網上作的分佈式傳輸算法，把它實時的傳輸到世界各地的機房。其次，能夠避免機房甚至骨幹網故障，對傳輸形成的影響。

如何實現高可用性

可用性能夠分爲兩個部分：接入可用性和使用可用性。你在使用服務的時候，可以接得進去，可以聽獲得，這是接入可用性。舉個例子，打電話的時候，有時會出現你所呼叫的用戶沒法接通，由於用戶的手機沒有接入電信服務，這就是接入可用性問題。在通話的時候，聽不到對方說話了，使用中掉線了，這就是使用可用性。

爲了實時監測可用性，咱們作了兩方面的監測：

一、主動監測

服務可用性不能依靠用戶數據反饋或者用戶主動上報，這樣你永遠是最後一個知道的。何況初期用戶量小怎麼辦？所以，咱們須要本身給出咱們的服務有多可靠。爲此，咱們研發主動監測系統來監測整個服務。端到端監測，接入有沒有問題，在使用的過程當中會不會出問題。

二、被動監測

用戶在使用咱們的服務的時候，咱們會收集用戶接入服務的整個過程，多長時間能夠接入，接入時通過了幾回請求，使用中有沒有掉線，中間有沒有聲音終端或卡頓。咱們會收集這些數據，據此瞭解服務的可用性。

有了監測數據，那麼就能夠據此來不斷改進咱們的服務，解決前面所說的挑戰。

一、覆蓋問題

在中國作互聯網的人應該都有一個感覺，聯通跨電信，用戶之間是難以交互的。早期的QQ傳文件沒有作中轉，若是聯通和電信的用戶要互相傳文件，速度很是慢，甚至會中斷。玩網遊的用戶，也會遇到有電信專區、網通專區。下圖是一個簡單的測試，當跨運營商的時候，發一個包，能夠看到裏面有不少丟包。這個數字是RTT，這個測試結果能夠看出，最小是62毫秒，最大是840毫秒。

不但中國有網絡互通的問題，國外也有。不少人覺得發達國家，好比美國、日本，互聯網的基礎設施較好，因此不會有互聯互通的問題。可是，在咱們作實際測試時，美國的互聯網也存在互聯互通的問題，只是情況比中國好一些。

上圖，展現了一個一個阿爾及利亞用戶的網絡情況。他接入的是國家電信的服務商，從骨幹網接入阿爾及利亞電信有不少線路，最下面的線路意大利電信是最直接的。若是不走意大利電信，那麼中間就必須通過不少運營商跳轉。在這種狀況下，要保證用戶有作最快的傳輸，就要保證傳輸走意大利電信。這必須依靠覆蓋來解決。

如何解決覆蓋問題？

首先，部署大量邊緣服務器。邊緣服務器的地理位置越接近用戶越好，兩者的線路越接近約好，同一個SP最好。好比中國國內，咱們會有大量電信、聯通、移動服務器。當咱們發現一個接入的用戶是電信時，咱們會找電信線路，若是是聯通的會找聯通線路。再看回上一個圖，若是遇到阿爾及利亞的用戶要怎麼辦？在如今的服務裏面咱們就要找一個意大利電信接入，而不是隨便找歐洲的機房。必須部署不少邊緣服務器才能作到這一點。

其次，要有分配服務。有邊緣服務器以後，用戶仍是沒法接入邊緣服務器，由於他不知道接哪一個。所以，必須有配套算法，根據用戶的SP，找到和他最匹配的邊緣服務器，來進行接入分配。

二、跨地域問題

咱們在全中國有好幾十個機房，其中有不少電信的機房，不一樣的電信用戶來使用咱們的服務，應該給他哪一個電信機房呢？若是把北京電信用戶接到廣州的電信機房，雖然大多數狀況下丟包不會很高，但延時會比較大。爲此，咱們設計了就近接入算法，使用咱們服務的每一個用戶，都會接入到最靠近他，且線路最匹配的服務器。

當咱們就近按SP接入時，遇到了一個新問題：假如一個香港用戶，接入的是香港機房，想看北京聯通用戶的表演，那麼這個香港用戶怎麼看到北京用戶的表演呢？咱們就須要有一個分佈式傳輸的架構和算法，來把北京的流量傳到香港。

三、DNS解析問題

今天無線互聯網很是普及，使用無線網時，有一個問題比有線網更嚴重：DNS解析。用戶接入時，第一步是經過域名解析，解析到最近的服務器。可是，作DNS解析時，無線網絡的信號會存在污染，致使DNS解析失敗。爲此，咱們優先使用解析，解析不到再用靜態IP配置。

四、骨幹網故障問題

咱們發如今骨幹網上，不少默認的骨幹網路由常常出問題，同時有一些骨幹網部分是不會擁堵的。基於這樣的發現，咱們作了本身的路由網絡。

在默認路由以外，咱們會額外部署路由機房。好比，從上海到洛杉磯，假設默認線路到晚上高峯期會比較擁堵，同時咱們發現從上海通過廣州再通過香港再到洛杉磯，這條線路不會擁堵。那麼，咱們就會部署這樣一條路由線路，而後作自動的適配。

若是骨幹網上出故障了，咱們經過路由的方式構建Overlay應對。首先，咱們的應用會先鏈接到分配服務，分配服務會給出一批可接入的機房，當接入的機房壞了，就當即切換到下一個可用機房，若是發現仍是壞了，則再次接入到分配服務，繼續尋找當前可用服務器。

五、蜂擁

蜂擁是實時互動直播裏面特別突出的現象，短期內大量用戶進入頻道或者使用服務。蜂擁對整個後臺的衝擊力很是強。大多數的互聯網的後臺服務器每秒接入大概千的量級，可是對於蜂擁而來的用戶，處理量遠遠不夠。這時候就會遇到一個問題，後臺處理響應速度愈來愈慢，不少用戶的請求會超時。超時以後就會進入更多的請求，請求就會像滾雪球同樣愈來愈大，致使整個後臺系統不能響應，整個系統就會產生雪崩，這叫雪崩效應。

如何防止雪崩效應

1）要把性能上限提升。一般來講咱們的性能上限會達到峯值處理能力10倍以上。性能上限提升要作分配服務性能擴展，咱們的作法通常是水平擴展，由於垂直擴展比較困難。

2）應用裏面作自動的重複請求，它會不斷累計請求量，咱們要作退避的策略。

3）保證整個接入服務自己的可用性問題，處理方法很簡單，多點備份，而後作併發的請求。咱們有不少分配的服務器，們的應用接入的時候會同時從幾個點請求分配，分配到一批邊緣服務器以後，會同時鏈接幾個邊緣服務器，哪一個先響應就處理哪一個。

本文整理自聲網Agora.io 1號架構師李偉，在ArchSummit深圳2016 全球架構師峯會 的演講。

【李偉】

2006年-2008年，在PP live工做的時候研發了PP live（已改名PPTV），當時最高有接近150萬人在線。2008年到2010年，在新浪負責新浪視頻的研發，2008年的歐冠直播，40萬人在線。2010年到2013年在YY工做，主要負責YY的架構，最高在線是超過一千萬，最大的單人頻道達150萬左右。2013年，加入聲網，負責聲網音視頻的系統架構。