高并發(fā)實時彈幕是一種互動的體驗。對于互動來說，考慮最多的地方就是：高穩(wěn)定性、高可用性以及低延遲這三個方面。

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序開發(fā)、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了陽新免費建站歡迎大家使用！

• 高穩(wěn)定性，為了保證互動的實時性，所以要求連接狀態(tài)穩(wěn)定；

• 高可用性，相當(dāng)于提供一種備用方案，比如，互動時如果一臺機器掛了，此時必須保證可以和另外一臺機器連接，這樣就從側(cè)面解決了，用戶連接不中斷的問題；

• 低延遲，彈幕的延遲周期控制在1秒以內(nèi)，響應(yīng)是比較快的，所以可以滿足互動的需求。

B站直播彈幕服務(wù)架構(gòu)（下面簡稱GOIM）的出現(xiàn)就是為了解決這一系列的需求。下面將對此進行詳細的介紹。

B站直播彈幕服務(wù)架構(gòu)GOIM的出現(xiàn)

圖 1

直播聊天系統(tǒng)本質(zhì)上也是一種推送系統(tǒng)，所謂推送系統(tǒng)就是，當(dāng)你發(fā)送一條消息時，它可以將這個消息推送給所有人。對于直播彈幕來說，用戶在不斷的發(fā)送消息，不斷的進行廣播，當(dāng)一個房間里面有10萬人時，一個消息就要發(fā)出10萬次請求。在GOIM出現(xiàn)之前，也用過另一個名為Gopush的項目，這個項目推出的目的就是進行推送。在此之后，基于一些針對性的應(yīng)用場景，GOIM對Gopush進行了優(yōu)化，從而出現(xiàn)在我們視野當(dāng)中。GOIM主要包含以下幾個模塊（圖1）：

1. Client

客戶端。與Comet建立鏈接。

2. Comet

維護客戶端長鏈接。在上面可以規(guī)定一些業(yè)務(wù)需求，比如可以規(guī)定用戶傳送的信息的內(nèi)容、輸送用戶信息等。Comet提供并維持服務(wù)端與客戶端之間的鏈接，這里保證鏈接可用性的方法主要是發(fā)送鏈接協(xié)議（如Socket等）。

3. Logic

對消息進行邏輯處理。用戶建立連接之后會將消息轉(zhuǎn)發(fā)給Logic，在Logic上可以進行賬號驗證。當(dāng)然，類似于IP過濾以及黑名單設(shè)置此類的操作也可以經(jīng)由Logic進行。

4. Router

存儲消息。Comet將信息傳送給Logic之后，Logic會對所收到的信息進行存儲，采用register session的方式在Router上進行存儲。Router里面會收錄用戶的注冊信息，這樣就可以知道用戶是與哪個機器建立的連接。

5. Kafka（第三方服務(wù)）

消息隊列系統(tǒng)。Kafka是一個分布式的基于發(fā)布/訂閱的消息系統(tǒng)，它是支持水平擴展的。每條發(fā)布到Kafka集群的消息都會打上一個名為Topic（邏輯上可以被認為是一個queue）的類別,起到消息分布式分發(fā)的作用。

6. Jop

消息分發(fā)?？梢云鸲鄠€Jop模塊放到不同的機器上進行覆蓋，將消息收錄之后，分發(fā)到所有的Comet上，之后再由Comet轉(zhuǎn)發(fā)出去。

以上就是GOIM系統(tǒng)實現(xiàn)客戶端建立鏈接，并進行消息轉(zhuǎn)發(fā)的一個具體過程。一開始這個結(jié)構(gòu)并不完善，在代碼層面也存在一些問題。鑒于這些問題，B站提供了一些相關(guān)的優(yōu)化操作。在高穩(wěn)定性方面，提供了內(nèi)存優(yōu)化、模塊優(yōu)化以及網(wǎng)絡(luò)優(yōu)化，下面是對這些優(yōu)化操作的介紹。

GOIM系統(tǒng)的優(yōu)化之路

內(nèi)存優(yōu)化

內(nèi)存優(yōu)化主要分為以下三個方面：

• 一個消息一定只有一塊內(nèi)存
  使用Job聚合消息，Comet指針引用

• 一個用戶的內(nèi)存盡量放到棧上
  內(nèi)存創(chuàng)建在對應(yīng)的用戶Goroutine（Go程）中

• 內(nèi)存由自己控制
  主要是針對Comet模塊所做的優(yōu)化，可以查看模塊中各個分配內(nèi)存的地方，使用內(nèi)存池

模塊優(yōu)化

模塊優(yōu)化也分為以下三方面：

• 消息分發(fā)一定是并行的并且互不干擾
  要保證到每一個Comet的通訊通道必須是相互獨立的，保證消息分發(fā)必須是完全并列的，并且彼此之間互不干擾。

• 并發(fā)數(shù)一定是可以進行控制的
  每個需要異步處理開啟的Goroutine（Go協(xié)程）都必須預(yù)先創(chuàng)建好固定的個數(shù)，如果不提前進行控制，那么Goroutine就隨時存在爆發(fā)的可能。

• 全局鎖一定是被打散的
  Socket鏈接池管理、用戶在線數(shù)據(jù)管理都是多把鎖；打散的個數(shù)通常取決于CPU，往往需要考慮CPU切換時造成的負擔(dān)，并非是越多越好。

模塊優(yōu)化的三個方面，主要考慮的問題就是，分布式系統(tǒng)中會出現(xiàn)的單點問題，即當(dāng)一個用戶在建立鏈接后，如果出現(xiàn)故障，其余用戶建立的鏈接不能被影響。

測試是實踐過程中最不可缺少的一部分，同時，測試的數(shù)據(jù)也是用來進行參考比照的最好工具。

圖 2

圖2是15年末的壓測數(shù)據(jù)。當(dāng)時使用了兩臺物理機，平均每臺的在線量是25萬，每個直播每秒的推送數(shù)量控制在20-50條內(nèi)。一般對于一個屏幕來說，40條就可以滿足直播的需求，當(dāng)時用來進行模擬的推送量是50條/秒（峰值），推送到達數(shù)是2440萬/秒。這次的數(shù)據(jù)顯示，CPU的負載是剛好滿，內(nèi)存使用量在4G左右，流量約為 3G。從這個數(shù)據(jù)得出的結(jié)論是，真正的瓶頸負載在CPU上。所以，目的很明確，就是將CPU負載打滿（但是不能超負載）。

圖 3

2015年之后，再次進行優(yōu)化，將所有內(nèi)存（堆上的、不可控的）都遷移到棧上，當(dāng)時只采用了一臺物理機，上面承載了100萬的在線數(shù)量。優(yōu)化效果體現(xiàn)在16年3月的壓測數(shù)據(jù)（圖3）中，這個數(shù)據(jù)也是最初直播時，想要測試的一個壓縮狀況。

從圖 3的數(shù)據(jù)可以看出，優(yōu)化效果是成倍增加的。當(dāng)時的目的也是將CPU打滿，可是在實際直播環(huán)境中，需要考慮的最本質(zhì)的問題其實是在流量上，包括彈幕字數(shù)、贈送禮物的數(shù)量。如果彈幕需要加上一些特殊的需求（字體、用戶等級等），贈送禮物數(shù)量過多這樣，都會產(chǎn)生很多流量。所以，直播彈幕優(yōu)化的最終瓶頸只有流量。

2016年之前，B站的優(yōu)化重點都放在了系統(tǒng)的優(yōu)化上，包括優(yōu)化內(nèi)存，降低CPU的使用率，可是優(yōu)化的效果并不顯著，一臺機器的瓶頸永遠是流量。在2016年3月份后，B站將優(yōu)化重點轉(zhuǎn)移到了網(wǎng)絡(luò)優(yōu)化上。下面就是B站網(wǎng)絡(luò)優(yōu)化的一些措施。

網(wǎng)絡(luò)優(yōu)化

最初B站的工作內(nèi)容，主要是以開發(fā)為主，為了在結(jié)構(gòu)上面得到擴展，所做的工作就是將代碼盡量完善。但是在實際業(yè)務(wù)當(dāng)中，也會遇見更多運維方面的問題，所以，在之后的關(guān)注重點上，B站添加了對運維的重點關(guān)注。

圖 4

圖4是B站早期的部署結(jié)構(gòu)。最開始，整套服務(wù)是部署在一個IDC上面的（單點IDC），時間一長，這樣的部署結(jié)構(gòu)也逐漸顯現(xiàn)出它的缺陷：

• 單線IDC流量不足

• 單點問題

• 接入率低

這樣的網(wǎng)絡(luò)部署往往會造成延遲高、網(wǎng)速卡頓等問題。

針對以上三點問題，B站也對部署結(jié)構(gòu)進行了改善，圖 5是改善過的網(wǎng)絡(luò)部署結(jié)構(gòu)，下面將對這個部署結(jié)構(gòu)進行詳細說明。

圖 5

針對單點IDC流量不足的問題，B站采用了多點IDC接入的方案。一個機房的流量不夠，那么就把它分散到不同的機房，看看效果如何。

對于多點IDC接入來說，專線的成本是非常高昂的，對于創(chuàng)業(yè)公司來說，是一塊很大的負擔(dān)，所以可以通過一些研發(fā)或者是架構(gòu)的方式來解決多IDC的問題 。針對多IDC的問題，需要優(yōu)化的方面還有很多，下面列舉出一些B站現(xiàn)有的一些優(yōu)化方案：

• 調(diào)節(jié)用戶最優(yōu)接入節(jié)點
  使用Svrlist模塊（圖6.1 ）支持，選取距離用戶最近的最穩(wěn)定的節(jié)點，調(diào)控IP段，然后進行接入。

• IDC 的服務(wù)質(zhì)量監(jiān)控：掉線率
  判斷一個節(jié)點是否穩(wěn)定，需要不斷收集大量的用戶鏈接信息，此時就可以使用監(jiān)控來查詢掉線率，然后不斷調(diào)優(yōu)，收集最終的結(jié)果去做一個拓撲圖（全國范圍），在拓撲圖當(dāng)中就可以判斷出城市到機房之間的最優(yōu)線路。

• 自動切走“失聯(lián)”服務(wù)器

• 消息100%的到達率（仍在實現(xiàn)中）
  對于彈幕來說，低丟包率是非常重要的。比如，消息是價值上千塊的禮物，此時一旦丟失某些消息，當(dāng)用戶發(fā)禮物時，起到的效果就是，實際在彈幕中顯示出來的效果是，禮物數(shù)遠遠少于用戶花費金錢買來的禮物數(shù)。這是一個很嚴重的問題。

• 流量控制
  對于彈幕來說，當(dāng)用戶量到達一定級別時，需要考慮的問題還是流量控制，這也是對于花銷成本的控制，當(dāng)買的機房的帶寬，是以千兆帶寬為計費標準時，當(dāng)有超標時，一定要將超標部分的流量切走，以此實現(xiàn)了流量控制的功能。

引入多點IDC接入之后，電信的用戶依舊可以走電信的線路，但是可以將模塊在其他機房進行部署，讓移動的一些用戶可以連接移動的機房。這樣就保證了，不同地區(qū)不同運營商之間，最優(yōu)網(wǎng)絡(luò)選取的問題。

可是解決了最優(yōu)網(wǎng)絡(luò)的選取，卻帶來了跨域傳輸?shù)膯栴}。比如在數(shù)據(jù)收集時，Comet模塊將數(shù)據(jù)反饋到Logic，Logic進行消息分發(fā)時，數(shù)據(jù)便會跨機房傳輸。有些公司的機房是通過專線進行傳輸，這樣成本將會非常高。所以，為了節(jié)約成本就只能走公網(wǎng)的流量，但是公網(wǎng)的穩(wěn)定性是否高、是否高可用，都是需要考慮的。當(dāng)流量從電信的機房出去之后，經(jīng)過電信的交換機，轉(zhuǎn)到聯(lián)通的交換機，然后到達聯(lián)通的機房，就會存在跨運營商傳輸?shù)膯栴}，比如丟包率高，因此，跨運營商傳輸帶來的問題還是非常嚴重的。

為了解決這個可能存在的風(fēng)險，可以嘗試在聯(lián)通機房接入一條電信的線路（帶寬可以小一點），“看管”電信的模塊，讓來自不同運營商的流量，可以走自己的線路。做了這樣的嘗試之后，不僅降低了丟包率，還滿足了對穩(wěn)定性的基本要求，并且成本消耗也不高?？墒?，這樣的方案也不能說是百分百的完美，因為就算是同運營商之間的通訊，也會存在城市和城市之間某個交換機出現(xiàn)故障的情況，對于這樣的情況，B站采取的方法是同時在IDC-1與IDC-2（圖 5）之間部署兩條電信線路，做了這樣的備份方案之后，通暢程度以及穩(wěn)定性都有非常明顯的提升。

針對上述過程中出現(xiàn)的一些問題，前期，需要對每個線路的穩(wěn)定性進行測試。為了測試每一條線路的穩(wěn)定性，可以把Comet放入各個機房中，并將Comet之間的通訊方式匯總成一個鏈接池（鏈接池里可以放多個運營商的多條線路），作為網(wǎng)絡(luò)鏈接可以將它配置成多條線路，用模塊檢測所有的Comet之間的通訊，以及任何線路傳輸?shù)姆€(wěn)定性，如果說通暢的話，則保證這個鏈接是可以用的（這里面有很多線路，所以一定會選擇通暢的那條線路進行傳輸，這樣，就可以判斷哪條線路是通暢的）這樣一來，流量進行傳輸時，就有多條線路可以進行選擇，三個運營商中，總有一個是可以服務(wù)的。

圖 6.1

綜合這些問題，B站又對結(jié)構(gòu)進行了重新優(yōu)化（這個結(jié)構(gòu)剛剛做完，目前還沒有上線，還需要經(jīng)過一些測試）。

首先是Comet的鏈接，之前采用的是CDN、智能DNS。但實際上，有些運營商基站會緩存路由表，所以即便將機器遷移走，部分用戶也并不能同時遷移走。而DNS解析這一塊，也并非完全可靠，而且一旦遇上問題，解決的流程又很長，這樣下來，體驗效果是十分糟糕的。其次是List，將其部署在一個中心機房，客戶端采用的是WEB接口的服務(wù)，讓客戶端訪問這個服務(wù)，就可以知道該與哪些服務(wù)器進行連接。將IP List（ Comet ）部署在多個機房，可以將多個機房收集的值反饋給客戶端（比如：哪些線路通暢）讓客戶端自己選擇與那個機器進行連接。

圖 6.2

如圖6.2，圖中將IP段進行了城市的劃分，將某一個城市的一些用戶信息鏈接到一個群組（GroupID），群組下有一個或多個Comet，把屬于這個群組的物理機全部分給Comet。

圖 7

圖7是再次優(yōu)化的結(jié)構(gòu)，還是將Comet全部放在IDC機房中，消息的傳輸不再使用push（推）的方式，而是通過pull（拉）的方式，將數(shù)據(jù)拉到中心機房（源站），做一些在線處理之后，再統(tǒng)一由源站進行數(shù)據(jù)推送。當(dāng)然，這里要十分注意中心機房的選取，中心機房的穩(wěn)定性是十分重要的。除此之外，B站在部署的時候還優(yōu)化了故障監(jiān)控這塊功能，用來保證高可用的服務(wù)。故障監(jiān)控主要為以下幾項：

• 模擬 Client ，監(jiān)控消息到達的速率

• 線上開啟 Ppof ，隨時抓圖分析進程（CPU ）狀況

• 白名單：指定人打印服務(wù)端日志

  • 設(shè)置白名單，記錄日志信息，收集問題反饋

  • 標注重點問題，及時解決

  • 防止消息重現(xiàn)

• 服務(wù)器負載監(jiān)控，短信報警

對于GOIM來說，低成本、高效率一直是B站所追求的標準，B站也將對系統(tǒng)進行持續(xù)優(yōu)化和改進，以給用戶最好的直播彈幕體驗。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前題目：bilibili高并發(fā)實時彈幕系統(tǒng)的實戰(zhàn)之路-創(chuàng)新互聯(lián)
分享鏈接：http://jinyejixie.com/article10/dehsdo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、商城網(wǎng)站、ChatGPT、企業(yè)網(wǎng)站制作、網(wǎng)站營銷、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)