如何實現百萬級的語音聊天室

上篇咱們介紹瞭如何從零開始搭建一套語音聊天室後臺，設計方案比較基礎，本篇咱們將介紹語音聊天室的升級版本——在海量用戶同時在線的狀況下，語音服務器的架構將如何升級改造。

互聯網產品後臺開發信奉一句話：先扛住再優化。工程師固然是但願把系統設計得盡善盡美，可是業務發展每每是不容許的，所以後臺工程師的工做就是在技術和業務之間尋找平衡點。大部分的系統都是逐步迭代演進而來的，沒有一蹴而就的完美系統。

前文中，咱們介紹了語音服務器分SET部署的概念。其實一直在迴避一個問題，分SET的缺點是什麼？

分SET限制了房間的容量。由於不分SET還好，分SET了之後一個房間撐死只能達到20萬的用戶，這樣看起來分SET是一個不合理的設計。真是這樣嗎？

固然不是。所謂萬丈高樓平地起，基礎架構是很是重要的。雖然分SET爲咱們帶來了一個限制，可是它的好處是更明顯的。首先，咱們的業務場景就決定了百萬級別的房間是不常見，咱們負責的超過20萬用戶在線的直播也就只有大型的遊戲賽事直播，並且這種直播一年也就那麼幾次。其次，前面已經說過，若是不分SET，應對百萬用戶房間，須要50臺機器，每次發佈出錯的影響面遠大於分SET部署。

所以，咱們要討論的不是分不分SET的問題，而是怎麼在分SET的狀況下，實現百萬房間的問題。

最容易想到的方案是把100萬用戶分到5個SET裏。那多個SET之間怎樣通訊呢？方法說白了就是爲不一樣SET中的服務器提供一個全局視圖，用於轉發路由。方法有不少種，這裏介紹2種思路。

第一種是在房間服務器的上面再增長一個組服務器（group server），爲系統提供全局視野。組服務器在每一個SET的語音服務器中選取一臺作爲橋頭堡機器（broker），跨SET轉發和接收都經過broker完成。Broker收到SET內轉發時，會將數據轉發給其餘SET的broker；而當收到跨SET轉發時，會將數據轉發給SET內的其餘機器。

 

 

這種方案的缺點是broker會成爲瓶頸，當broker宕機時，最嚴重的狀況是形成其餘SET沒法提供服務。容災策略一種是減小broker到組服務器的心跳間隔，使組服務器能夠迅速發現異常並從新挑選broker；另外一種方法是採用雙broker，不過會增長數據去重的複雜度。

第二種是在系統以外增長一個轉發服務器，專門負責跨SET轉發，固然它自己擁有全局視野。這種方案實際上是把上面說的組服務和雙broker結合在一塊兒，把轉發功能外化。對於跨SET房間，主播所在的語音服務器作SET內轉發的同時將數據發給轉發服務器，轉發服務器根據房間信息將數據轉發給其餘SET的任意1臺機器。

 

這樣優勢很是明顯，轉發服務器跟原有系統徹底解耦，原系統改造也很小，能夠實現高可用。惟一缺點是轉發服務器起碼有兩臺機器，也會增長接收方數據去重的複雜度。

如今咱們梳理一下，要實現一個支持百萬級的語音聊天房間，總體的架構以下所示：

 

1. 用戶建立房間。經過目錄服務器建立，其實是在數據庫中增長一條set_id和room_id的映射記錄。
2. 用戶請求進入房間。經過目錄服務器查詢應該連到哪臺語音服務器，具體的邏輯由負載均衡服務器實現。簡單描述爲：查詢到room_id所在的set的全部語音服務器，根據負載狀況和就近接入原則，選擇幾臺語音服務器的ip和端口返回。
3. 用戶進入房間。客戶端鏈接語音服務器，語音服務器將進房請求透傳給房間服務器，房間服務器記錄房間架構信息，並按期同步給set內全部的語音服務器。
4. 對於小房間，經過set內轉發語音實現。

對於跨set的大房間，由多個房間服務器協同工做實現。房間服務器之間不須要互相通訊，它們只要在set內按規則挑選一臺語音服務器做爲broker。Broker收到語音數據時，除了常規的set內轉發外，還將數據發給轉發服務器。轉發服務器知道房間所在的set列表和每一個set的broker，從而實現跨set轉發。

    本篇主要介紹了基於分SET架構如何實現百萬級房間的設計方法，並梳理了語音聊天室的總體架構。但願對你們有所幫助。