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

直播間特點

聊天室限制人數的原因

應對萬級以上的實時互動

跨服務器是為了解決單一服務器接入數量限制、發布消息吞吐限制等問題；

多進程并發則是為了充分利用多核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以內。除此以外，還能夠擴大任務池，提升系統并發能力。