?2016-2026 Matools All rights reserved,
粵ICP備17059708號
上篇我們介紹了如何從零開始搭建一套語音聊天室后臺，設計方案比較基礎，本篇我們將介紹語音聊天室的升級版本——在海量用戶同時在線的情況下，語音服務器的架構將如何升級改造。
互聯(lián)網產品后臺開發(fā)信奉一句話：先扛住再優(yōu)化。工程師當然是希望把系統(tǒng)設計得盡善盡美，但是業(yè)務發(fā)展往往是不允許的，因此后臺工程師的工作就是在技術和業(yè)務之間尋找平衡點。大部分的系統(tǒng)都是逐步迭代演進而來的，沒有一蹴而就的完美系統(tǒng)。
前文中，我們介紹了語音服務器分SET部署的概念。其實一直在回避一個問題，分SET的缺點是什么？
分SET限制了房間的容量。因為不分SET還好，分SET了以后一個房間撐死只能達到20萬的用戶，這樣看起來分SET是一個不合理的設計。真是這樣嗎？
當然不是。所謂萬丈高樓平地起，基礎架構是非常重要的。雖然分SET為我們帶來了一個限制，但是它的好處是更明顯的。首先，我們的業(yè)務場景就決定了百萬級別的房間是不常見，我們負責的超過20萬用戶在線的直播也就只有大型的游戲賽事直播，而且這種直播一年也就那么幾回。其次，前面已經說過，如果不分SET，應對百萬用戶房間，需要50臺機器，每次發(fā)布出錯的影響面遠大于分SET部署。
因此，我們要討論的不是分不分SET的問題，而是怎么在分SET的情況下，實現百萬房間的問題。
最容易想到的方案是把100萬用戶分到5個SET里。那多個SET之間怎樣通信呢？方法說白了就是為不同SET中的服務器提供一個全局視圖，用于轉發(fā)路由。方法有很多種，這里介紹2種思路。
第一種是在房間服務器的上面再增加一個組服務器（group server），為系統(tǒng)提供全局視野。組服務器在每個SET的語音服務器中選取一臺做為
橋頭堡機器（broker）
，跨SET轉發(fā)和接收都通過broker完成。Broker收到SET內轉發(fā)時，會將數據轉發(fā)給其他SET的broker；而當收到跨SET轉發(fā)時，會將數據轉發(fā)給SET內的其他機器。
?
?
這種方案的缺點是broker會成為瓶頸，當broker宕機時，最嚴重的情況是造成其他SET無法提供服務。容災策略一種是減少broker到組服務器的心跳間隔，使組服務器可以迅速發(fā)現異常并重新挑選broker；另一種方法是采用雙broker，不過會增加數據去重的復雜度。
第二種是在系統(tǒng)之外增加一個轉發(fā)服務器
，專門負責跨SET轉發(fā)，當然它本身擁有全局視野。這種方案其實是把上面說的組服務和雙broker結合在一起，把轉發(fā)功能外化。對于跨SET房間，主播所在的語音服務器做SET內轉發(fā)的同時將數據發(fā)給轉發(fā)服務器，轉發(fā)服務器根據房間信息將數據轉發(fā)給其他SET的任意1臺機器。
?
這樣優(yōu)點非常明顯，轉發(fā)服務器跟原有系統(tǒng)完全解耦，原系統(tǒng)改造也很小，可以實現高可用。唯一缺點是轉發(fā)服務器起碼有兩臺機器，也會增加接收方數據去重的復雜度。
現在我們梳理一下，要實現一個支持百萬級的語音聊天房間，整體的架構如下所示：
?
* 用戶創(chuàng)建房間。通過目錄服務器創(chuàng)建，實際上是在數據庫中增加一條set_id和room_id的映射記錄。
*
用戶請求進入房間。通過目錄服務器查詢應該連到哪臺語音服務器，具體的邏輯由負載均衡服務器實現。簡單描述為：查詢到room_id所在的set的所有語音服務器，根據負載情況和就近接入原則，選擇幾臺語音服務器的ip和端口返回。
* 用戶進入房間?？蛻舳诉B接語音服務器，語音服務器將進房請求透傳給房間服務器，房間服務器記錄房間架構信息，并定期同步給set內所有的語音服務器。
* 對于小房間，通過set內轉發(fā)語音實現。
對于跨set的大房間，由多個房間服務器協(xié)同工作實現。房間服務器之間不需要互相通信，它們只要在set內按規(guī)則挑選一臺語音服務器作為broker。Broker收到語音數據時，除了常規(guī)的set內轉發(fā)外，還將數據發(fā)給轉發(fā)服務器。轉發(fā)服務器知道房間所在的set列表和每個set的broker，從而實現跨set轉發(fā)。
??? 本篇主要介紹了基于分SET架構如何實現百萬級房間的設計方法，并梳理了語音聊天室的整體架構。希望對大家有所幫助。
熱門工具 換一換