嗶哩嗶哩高併發實時彈幕系統架構演進

直播聊天系統本質上也是一種推送系統，所謂推送系統就是，當你發送一條消息時，它能夠將這個消息推送給全部人。對於直播彈幕來講，用戶在不斷地發送消息，不斷地進行廣播，當一個房間裏面有 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 切換時形成的負擔，並不是是越多越好。

模塊優化的三個方面，主要考慮的問題就是，分佈式系統中會出現的單點問題，即當一個用戶在創建連接後，若是出現故障，其他用戶創建的連接不能被影響。

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