原文地址：https://blog.csdn.net/zhiboshequ/article/details/68489960點此開啟原文站點

高併發實時彈幕是一種互動的體驗。對於互動來說，考慮最多的地方就是：高穩定性、高可用性以及低延遲這三個方面。

• 高穩定性，為了保證互動的實時性，所以要求連線狀態穩定；

• 高可用性，相當於提供一種備用方案，比如，互動時如果一臺機器掛了，此時必須保證可以和另外一臺機器連線，這樣就從側面解決了，使用者連線不中斷的問題；

• 低延遲，彈幕的延遲週期控制在1秒以內，響應是比較快的，所以可以滿足互動的需求。

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

B站直播彈幕服務架構GOIM的出現

圖1

直播聊天系統本質上也是一種推送系統，所謂推送系統就是，當你傳送一條訊息時，它可以將這個訊息推送給所有人。對於直播彈幕來說，使用者在不斷地傳送訊息，不斷地進行廣播，當一個房間裡面有
10 萬人時，一個訊息就要發出 10 萬次請求。在 GOIM 出現之前，也用過另一個名為 Gopush
的專案，這個專案推出的目的就是進行推送。在此之後，基於一些針對性的應用場景，GOIM 對 Gopush
進行了優化，從而出現在我們視野當中。GOIM 主要包含以下幾個模組（圖 1）：

• Kafka（第三方服務）
  訊息佇列系統。Kafka 是一個分散式的基於釋出/訂閱的訊息系統，它是支援水平擴充套件的。每條釋出到
  Kafka 叢集的訊息都會打上一個名為 Topic（邏輯上可以被認為是一個 queue）的類別,起到訊息分散式分發的作用。

• Router 
  儲存訊息。Comet 將資訊傳送給 Logic 之後，Logic 會對所收到的資訊進行儲存，採用
  register session 的方式在 Router 上進行儲存。Router 裡面會收錄使用者的註冊資訊，這樣就可以知道使用者是與哪個機器建立的連線。

• Logic
  對訊息進行邏輯處理。使用者建立連線之後會將訊息轉發給 Logic ，在 Logic
  上可以進行賬號驗證。當然，類似於 IP 過濾以及黑名單設定此類的操作也可以經由 Logic 進行。

• Comet
  維護客戶端長連結。在上面可以規定一些業務需求，比如可以規定使用者傳送的資訊的內容、輸送使用者資訊等。Comet
  提供並維持服務端與客戶端之間的連結，這裡保證連結可用性的方法主要是傳送連結協議（如 Socket 等）。

• Client
  客戶端。與 Comet 建立連結。

• Jop 
  訊息分發。可以起多個 Jop 模組放到不同的機器上進行覆蓋，將訊息收錄之後，分發到所有的
  Comet 上，之後再由 Comet 轉發出去。

以上就是 GOIM 系統實現客戶端建立連結，並進行訊息轉發的一個具體過程。一開始這個結構並不完善，在程式碼層面也存在一些問題。鑑於這些問題，B
站提供了一些相關的優化操作。在高穩定性方面，提供了記憶體優化、模組優化以及網路優化，下面是對這些優化操作的介紹。

GOIM
系統的優化之路

記憶體優化

記憶體優化主要分為以下三個方面：

1.一個訊息一定只有一塊記憶體

使用 Job 聚合訊息，Comet 指標引用。

2.一個使用者的記憶體儘量放到棧上

記憶體建立在對應的使用者 Goroutine（Go 程）中。

3.記憶體由自己控制

主要是針對 Comet 模組所做的優化，可以檢視模組中各個分配記憶體的地方，使用記憶體池。

模組優化

模組優化也分為以下三方面：

1.訊息分發一定是並行的並且互不干擾

要保證到每一個 Comet 的通訊通道必須是相互獨立的，保證訊息分發必須是完全並列的，並且彼此之間互不干擾。

2.併發數一定是可以進行控制的

每個需要非同步處理開啟的 Goroutine（Go 協程）都必須預先建立好固定的個數，如果不提前進行控制，那麼
Goroutine 就隨時存在爆發的可能。

3.全域性鎖一定是被打散的

Socket 連結池管理、使用者線上資料管理都是多把鎖；打散的個數通常取決於
CPU，往往需要考慮 CPU 切換時造成的負擔，並非是越多越好。

模組優化的三個方面，主要考慮的問題就是，分散式系統中會出現的單點問題，即當一個使用者在建立連結後，如果出現故障，其餘使用者建立的連結不能被影響。

測試是實踐過程中最不可缺少的一部分，同時，測試的資料也是用來進行參考比照的最好工具。

圖2

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

圖3

2015 年之後，再次進行優化，將所有記憶體（堆上的、不可控的）都遷移到棧上，當時只採用了一臺物理機，上面承載了
100 萬的線上數量。 優化效果體現在 2016 年 3 月的壓測資料（圖 3）中，這個資料也是最初直播時，想要測試的一個壓縮狀況。

從圖
3 的資料可以看出，優化效果是成倍增加的。當時的目的也是將 CPU
打滿，可是在實際直播環境中，需要考慮的最本質的問題其實是在流量上，包括彈幕字數，贈送禮物的數量。如果彈幕需要加上一些特殊的需求（字型、使用者等級等），贈送禮物數量過多這樣，都會產生很多流量。所以，直播彈幕優化的最終瓶頸只有流量。

2016 年之前，B 站的優化重點都放在了系統的優化上，包括優化記憶體，降低
CPU 的使用率，可是優化的效果並不顯著，一臺機器的瓶頸永遠是流量。在 2016 年 3 月份後，B 站將優化重點轉移到了網路優化上。下面就是 B 站網路優化的一些措施。

網路優化

最初 B 站的工作內容，主要是以開發為主，為了在結構上面得到擴充套件，所做的工作就是將程式碼儘量完善。但是在實際業務當中，也會遇見更多運維方面的問題，所以，在之後的關注重點上，B
站添加了對運維的重點關注。

 
圖 4

圖 4 是 B 站早期的部署結構。最開始，整套服務是部署在一個 IDC 上面的（單點
IDC），時間一長，這樣的部署結構也逐漸顯現出它的缺陷：

• 單線 IDC 流量不足

• 單點問題

• 接入率低
  這樣的網路部署往往會造成延遲高、網速卡頓等問題。

針對以上三點問題，B 站也對部署結構進行了改善，圖 5 是改善過的網路部署結構，下面將對這個部署結構進行詳細說明。
圖 5

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

對於多點 IDC 接入來說，專線的成本是非常高昂的，對於創業公司來說，是一塊很大的負擔，所以可以通過一些研發或者是架構的方式來解決多
IDC 的問題 。針對多 IDC 的問題，需要優化的方面還有很多，下面列舉出一些 B 站現有的一些優化方案：

1.調節使用者最優接入節點

使用 Svrlist 模組（圖 6.1）支援，選取距離使用者最近的最穩定的節點，調控
IP 段，然後進行接入。

圖 6.1

2.IDC 的服務質量監控：掉線率

判斷一個節點是否穩定，需要不斷收集大量的使用者連結資訊，此時就可以使用監控來查詢掉線率，然後不斷調優，收集最終的結果去做一個拓撲圖（全國範圍），在拓撲圖當中就可以判斷出城市到機房之間的最優線路。

3.自動切走「失聯」伺服器

4.訊息 100%的到達率（仍在實現中）

對於彈幕來說，低丟包率是非常重要的。比如，訊息是價值上千塊的禮物，此時一旦丟失某些訊息，當用戶發禮物時，起到的效果就是，實際在彈幕中顯示出來的效果是，禮物數遠遠少於使用者花費金錢買來的禮物數。這是一個很嚴重的問題。

5.流量控制

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

引入多點 IDC 接入之後，電信的使用者依舊可以走電信的線路，但是可以將模組在其他機房進行部署，讓移動的一些使用者可以連線移動的機房。這樣就保證了，不同地區不同運營商之間，最優網路選取的問題。

可是解決了最優網路的選取，卻帶來了跨域傳輸的問題。比如在資料收集時，Comet
模組將資料反饋到 Logic，Logic
進行訊息分發時，資料便會跨機房傳輸。有些公司的機房是通過專線進行傳輸，這樣成本將會非常高。所以，為了節約成本就只能走公網的流量，但是公網的穩定性是否高、是否高可用，都是需要考慮的。當流量從電信的機房出去之後，經過電信的交換機，轉到聯通的交換機，然後到達聯通的機房，就會存在跨運營商傳輸的問題，比如丟包率高，因此，跨運營商傳輸帶來的問題還是非常嚴重的。

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

針對上述過程中出現的一些問題，前期，需要對每個線路的穩定性進行測試。為了測試每一條線路的穩定性，可以把
Comet 放入各個機房中，並將 Comet
之間的通訊方式彙總成一個連結池（連結池裡可以放多個運營商的多條線路），作為網路連結可以將它配置成多條線路，用模組檢測所有的 Comet
之間的通訊，以及任何線路傳輸的穩定性，如果說通暢的話，則保證這個連結是可以用的。（這裡面有很多線路，所以一定會選擇通暢的那條線路進行傳輸，這樣，就可以判斷哪條線路是通暢的。）這樣一來，流量進行傳輸時，就有多條線路可以進行選擇，三個運營商中，總有一個是可以服務的。

綜合這些問題，B 站又對結構進行了重新優化。（這個結構剛剛做完，目前還沒有上線，還需要經過一些測試。）

圖 6.2

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

如圖 6.2 。圖中將 IP 段進行了城市的劃分，將某一個城市的一些使用者資訊連結到一個群組（GroupID），群組下有一個或多個
Comet ，把屬於這個群組的物理機全部分給 Comet 。

圖 7

圖
7 是再次優化的結構，還是將 Comet 全部放在 IDC 機房中，訊息的傳輸不再使用
push（推）的方式，而是通過
pull（拉）的方式，將資料拉到中心機房（源站），做一些線上處理之後，再統一由源站進行資料推送。當然，這裡要十分注意中心機房的選取，中心機房的穩定性是十分重要的。除此之外，B
站在部署的時候還優化了故障監控這塊功能，用來保證高可用的服務。故障監控主要為以下幾項：

1.模擬 Client ，監控訊息到達的速率

2.線上開啟 Ppof ，隨時抓圖分析程序（CPU）狀況

3.白名單：指定人列印服務端日誌

設定白名單，記錄日誌資訊，收集問題反饋

標註重點問題，及時解決

防止訊息重現

4.伺服器負載監控，簡訊報警

低成本、高效率一直是 B 站所追求的標準，B 站將對 GOIM 系統進行持續優化和改進，以給使用者最好的直播彈幕體驗。