高併發實時直播彈幕研發實踐

高併發實時直播彈幕研發實踐

直播間特色

聊天室限制人數的緣由

應對萬級以上的實時互動

跨服務器是爲了解決單一服務器接入數量限制、發佈消息吞吐限制等問題；
多進程併發則是爲了充分利用多核CPU以及減少一個循環規模從而達到下降延遲的目的。

雲巴實時系統的設計

雲巴是基於MQTT協議實現的實時通訊系統，採用Erlang/OTP的架構設計。簡單地來講，雲巴實時系統的設計包括多層結構、微服務兩個要點。

多層結構

雲巴系統設計中，多層結構意味着一個基本業務邏輯的完成須要經歷多個模塊（如圖上所示）。

雲巴多層結構設計有三個主要特色：

• 全部模塊都可獨立運行，互不干擾。 任一模塊在運行的過程當中，無需依賴其餘模塊。除此之外，還會對全部模塊設立在線監控，從而實現生產狀態下的實時告警。同時，模塊獨立運行還可以達到持續集成的效果；

• 細粒度擴容，包括但不限於對接入進行擴容等；

• 使用「隔離」。 顧名思義，系統能夠爲用戶指定特定的路徑，也能夠在某些路徑出現問題之後，強行從系統裏摘除路徑，達到「隔離」效果。

微服務化

雖然近期微服務已一個新興事物的身份被普遍討論，但其實，微服務能夠算是一個老 概念了。

好比Erlang/OTP就是一個成熟已久的典型微服務架構。其做爲微服務架構的特色就在於業務邏輯很是簡單的同時，併發量也很是高。

雲巴採用的正是Erlang/OTP的架構設計，在微服務化的方面的體現則是將業務邏輯封裝成一個RPC Service，以及RPC Service部署微一個OTP Worker。

雲巴實時系統的特色

雲巴實時系統的設計特色主要有：擁有海量輕量級任務、任務與運行位置無關以及水平擴展。任務與運行位置無關，這就意味着在任務池中，能夠動態地把任務調度到不一樣物理機上，同時數據要存儲在獨立集羣中。

海量的輕量級任務包括長鏈接建立的任務、用戶請求產生時建立的任務。

長鏈接任務即爲，當一個長鏈接接入時，系統會建立一個任務來管理和維持長鏈接；

一樣地，請求任務則是，當一個用戶請求（好比發送一條彈幕）產生時，就會建立一個任務來管理該請求。

對於雲巴來說，不管是用戶加入了一個直播間仍是發送了一條彈幕，均可以以Pub/Sub模型來實現。Pub/Sub模型中比較重要的詞彙爲「publish」、「subscribe」以及「unsubscribe」。

好比，一個用戶進入了一個直播間，則能夠視爲訂閱（subscribe）了該直播間；

進入以後在直播間發送彈幕，視爲向這個直播間發送（publish）了一條消息；

而因爲進入直播間的用戶都已經訂閱過該直播間，因此其餘用戶都看到了這條彈幕。

一旦用戶退出了直播間，則視爲取消訂閱（unsubscribe）了直播間，再也收不到該直播間裏面其餘用戶發佈的彈幕了。

傳統的消息發佈過程

傳統的消息發佈過程有兩種，第一種是遍歷列表裏的每個UID,讀取路由，逐一發送消息；

第二種是遍歷每一臺服務器，發送消息，而後將訂閱關係保存在每一臺服務器內。以上兩種作法都有可能致使延遲過多的問題。

雲巴的消息發佈過程

在雲巴，消息的發佈過程爲，首先在接收到任務請求後，會發布任務計算UID列表分片，對總任務進行分片處理。以後將分片任務分發給任務池，執行各個分片任務。最後，發佈任務匯聚請求，返回全部的分片任務。

「分片」——「匯聚」設計的好處在於，能夠有效控制最大延遲。目前雲巴是將此整個過程控制在200ms之內。除此之外，還可以擴大任務池，提高系統併發能力。

雲巴彈幕Demo