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

2021-09-18 02:21:01 字數 4194 閱讀 9952

現在比較流行的直播,經常會出現這樣的情況: 使用者打了乙個彈幕上去,主播念出來的時候,彈幕已經飛出去了。二者時間是不匹配的。

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

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

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

第一,網際網路的骨幹網上路由器的部署,不是直線點到點,而是中間要經過很多路由器的跳數,實際上是在走「彎路」。所以,網際網路傳輸沒有辦法繞地球一圈正好300毫秒,最好的情況也需要要近400毫秒。

第二,公共網際網路上,路由器其實經常出現故障。比如,在晚高峰的時候,網路會比較慢。這是因為部分路由器可能過載。因為路由器有最大的處理能力上限,一旦超過上限,就不能處理,會造成丟包、擁塞。

第三,無線網路相對有線網路,可靠性較低。無線網路普及度越來越高,,越來越多的手機、筆記本連線無線網。但是無線網路相對有線網路沒有那麼可靠,同時也會引入訊號汙染。訊號覆蓋不到的地方,效果較差。

實時互動直播要保證高可用性,有巨大的難度,原因如下:

實時很難。網際網路基礎設施不是為實時通訊設計的。

覆蓋很難。機房找點,互聯互通。對通訊雲來說,覆蓋不好會影響到可用性。

高併發很難。不能看著看著就不動了,沒聲了。

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

這些挑戰我們在做整個服務的時候,都需要全面考慮。

這個架構很簡單,但有乙個缺點,沒有考慮覆蓋不同地使用者的問題。並且一台伺服器支撐不了大規模使用者。這台伺服器如果宕機,或者伺服器機房出故障,整個傳輸都會受到影響。這必然達不到高可用架構的標準。

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

為了實時監測可用性,我們做了兩方面的監測:

1、主動監測

服務可用性不能依靠使用者資料反饋或者使用者主動上報,這樣你永遠是最後乙個知道的。況且初期使用者量小怎麼辦?因此,我們需要自己給出我們的服務有多可靠。為此,我們研發主動監測系統來監測整個服務。端到端監測,接入有沒有問題,在使用的過程中會不會出問題。

2、被動監測

使用者在使用我們的服務的時候,我們會收集使用者接入服務的整個過程,多長時間可以接入,接入時經過了幾次請求,使用中有沒有掉線,中間有沒有聲音終端或卡頓。我們會收集這些資料,據此了解服務的可用性。

有了監測資料,那麼就可以據此來不斷改進我們的服務,解決前面所說的挑戰。

在中國做網際網路的人應該都有乙個感受,聯通跨電信,使用者之間是難以互動的。早期的qq傳檔案沒有做中轉,如果聯通和電信的使用者要互相傳檔案,速度非常慢,甚至會中斷。玩網遊的使用者,也會遇到有電信專區、網通專區。下圖是乙個簡單的測試,當跨運營商的時候,發乙個包,可以看到裡面有很多丟包。這個數字是rtt,這個測試結果可以看出,最小是62毫秒,最大是840毫秒。

不但中國有網路互通的問題,國外也有。很多人以為發達國家,比如美國、日本,網際網路的基礎設施較好,所以不會有互聯互通的問題。但是,在我們做實際測試時,美國的網際網路也存在互聯互通的問題,只是狀況比中國好一些。

上圖,展示了乙個乙個阿爾及利亞使用者的網路狀況。他接入的是國家電信的服務商,從骨幹網接入阿爾及利亞電信有很多線路,最下面的線路義大利電信是最直接的。如果不走義大利電信,那麼中間就必須經過很多運營商跳轉。在這種情況下,要保證使用者有做最快的傳輸,就要保證傳輸走義大利電信。這必須依靠覆蓋來解決。

如何解決覆蓋問題?

首先,部署大量邊緣伺服器。邊緣伺服器的地理位置越接近使用者越好,二者的線路越接近約好,同乙個sp最好。比如中國國內,我們會有大量電信、聯通、移動伺服器。當我們發現乙個接入的使用者是電信時,我們會找電信線路,如果是聯通的會找聯通線路。再看回上乙個圖,如果遇到阿爾及利亞的使用者要怎麼辦?在現在的服務裡面我們就要找乙個義大利電信接入,而不是隨便找歐洲的機房。必須部署很多邊緣伺服器才能做到這一點。

其次,要有分配服務。有邊緣伺服器之後,使用者還是無法接入邊緣伺服器,因為他不知道接哪個。因此,必須有配套演算法,根據使用者的sp,找到和他最匹配的邊緣伺服器,來進行接入分配。

我們在全中國有好幾十個機房,其中有很多電信的機房,不同的電信使用者來使用我們的服務,應該給他哪個電信機房呢?如果把北京電信使用者接到廣州的電信機房,雖然大多數情況下丟包不會很高,但延時會比較大。為此,我們設計了就近接入演算法,使用我們服務的每個使用者,都會接入到最靠近他,且線路最匹配的伺服器。

當我們就近按sp接入時,遇到了乙個新問題:假如乙個香港使用者,接入的是香港機房,想看北京聯通使用者的表演,那麼這個香港使用者怎麼看到北京使用者的表演呢?我們就需要有乙個分布式傳輸的架構和演算法,來把北京的流量傳到香港。

今天無線網際網路非常普及,使用無線網時,有乙個問題比有線網更嚴重:dns解析。使用者接入時,第一步是通過網域名稱解析,解析到最近的伺服器。但是,做dns解析時,無線網路的訊號會存在汙染,導致dns解析失敗。為此,我們優先使用解析,解析不到再用靜態ip配置。

我們發現在骨幹網上,很多預設的骨幹網路由經常出問題,同時有一些骨幹網部分是不會擁堵的。基於這樣的發現,我們做了自己的路由網路。

在預設路由之外,我們會額外部署路由機房。比如,從上海到洛杉磯,假設預設線路到晚上高峰期會比較擁堵,同時我們發現從上海經過廣州再經過香港再到洛杉磯,這條線路不會擁堵。那麼,我們就會部署這樣一條路由線路,然後做自動的適配。

如果骨幹網上出故障了,我們通過路由的方式構建overlay應對。首先,我們的應用會先連線到分配服務,分配服務會給出一批可接入的機房,當接入的機房壞了,就立即切換到下乙個可用機房,如果發現還是壞了,則再次接入到分配服務,繼續尋找當前可用伺服器。

蜂擁是實時互動直播裡面特別突出的現象,短時間內大量使用者進入頻道或者使用服務。蜂擁對整個後台的衝擊力非常強。大多數的網際網路的後台伺服器每秒接入大概千的量級,但是對於蜂擁而來的使用者,處理量遠遠不夠。這時候就會遇到乙個問題,後台處理響應速度越來越慢,很多使用者的請求會超時。超時之後就會進入更多的請求,請求就會像滾雪球一樣越來越大,導致整個後台系統不能響應,整個系統就會產生雪崩,這叫雪崩效應。

1)要把效能上限提高。通常來說我們的效能上限會達到峰值處理能力10倍以上。效能上限提高要做分配服務效能擴充套件,我們的做法一般是水平擴充套件,因為垂直擴充套件比較困難。

2)應用裡面做自動的重複請求,它會不斷累計請求量,我們要做退避的策略。

3)保證整個接入服務本身的可用性問題,處理方法很簡單,多點備份,然後做併發的請求。我們有很多分配的伺服器,們的應用接入的時候會同時從幾個點請求分配,分配到一批邊緣伺服器之後,會同時連線幾個邊緣伺服器,哪個先響應就處理哪個。

本文整理自聲網agora.io 1號架構師李偉,在archsummit深圳2016 全球架構師峰會 的演講。

【李偉】

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

現在比較流行的直播,經常會出現這樣的情況 使用者打了乙個彈幕上去,主播念出來的時候,彈幕已經飛出去了。二者時間是不匹配的。這是我們的乙個客戶,兩個主播連線互動,實時互動。試想,如果直播時延時高達幾秒,像這樣的雙主播組合是沒有辦法進行交談的。a說完之後,對方要等幾秒才能聽到,又過了幾秒,a才能聽到對方...

海量實時使用者行為資料的儲存和分析

在短時間內爆發大量資料,這時資料資源的採集 儲存和分析和應用等,都是大資料行業的難點。行為資料 日誌資料的處理,往往成為企業資料建設首先面對的瓶頸,這些資料不易儲存,實時獲取分析難度較大,但是資料價值卻不可估量。在大資料中,90 以上的資料爆發來自於行為資料,就像現在的網際網路 移動網際網路 甚至在...

基於sersync海量檔案實時同步

基於sersync海量檔案實時同步 專案需求 最近涉及到數百萬張從本地儲存遷移到雲儲存,為了使完成遷移,並保證無缺失,業務不中斷,決定採用實時同步,同步完後再做流量切換。在實時同步方案中進行了幾種嘗試。方案1 rsync inotify同步,最先想到的是此方案,先看下指令碼 此前在多台伺服器間同步 ...