上篇我們介紹了如何從零開始搭建一套語音聊天室后台，設計方案比較基礎，本篇我們將介紹語音聊天室的升級版本——在海量用戶同時在線的情況下，語音服務器的架構將如何升級改造。
互聯網產品后台開發信奉一句話：先扛住再優化。工程師當然是希望把系統設計得盡善盡美，但是業務發展往往是不允許的，因此后台工程師的工作就是在技術和業務之間尋找平衡點。大部分的系統都是逐步迭代演進而來的，沒有一蹴而就的完美系統。
前文中，我們介紹了語音服務器分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台機器。
這樣優點非常明顯，轉發服務器跟原有系統完全解耦，原系統改造也很小，可以實現高可用。唯一缺點是轉發服務器起碼有兩台機器，也會增加接收方數據去重的復雜度。
現在我們梳理一下，要實現一個支持百萬級的語音聊天房間，整體的架構如下所示：
- 用戶創建房間。通過目錄服務器創建，實際上是在數據庫中增加一條set_id和room_id的映射記錄。
- 用戶請求進入房間。通過目錄服務器查詢應該連到哪台語音服務器，具體的邏輯由負載均衡服務器實現。簡單描述為：查詢到room_id所在的set的所有語音服務器，根據負載情況和就近接入原則，選擇幾台語音服務器的ip和端口返回。
- 用戶進入房間。客戶端連接語音服務器，語音服務器將進房請求透傳給房間服務器，房間服務器記錄房間架構信息，並定期同步給set內所有的語音服務器。
- 對於小房間，通過set內轉發語音實現。
對於跨set的大房間，由多個房間服務器協同工作實現。房間服務器之間不需要互相通信，它們只要在set內按規則挑選一台語音服務器作為broker。Broker收到語音數據時，除了常規的set內轉發外，還將數據發給轉發服務器。轉發服務器知道房間所在的set列表和每個set的broker，從而實現跨set轉發。
本篇主要介紹了基於分SET架構如何實現百萬級房間的設計方法，並梳理了語音聊天室的整體架構。希望對大家有所幫助。