直播間特點
聊天室限制人數的原因
應對萬級以上的實時互動
跨服務器是為了解決單一服務器接入數量限制、發布消息吞吐限制等問題； 多進程並發則是為了充分利用多核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以內。除此以外，還能夠擴大任務池，提升系統並發能力。