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

網際網路產品後臺開發信奉一句話：先扛住再優化。工程師當然是希望把系統設計得盡善盡美，但是業務發展往往是不允許的，因此後臺工程師的工作就是在技術和業務之間尋找平衡點。大部分的系統都是逐步迭代演進而來的，沒有一蹴而就的完美系統。

前文中，我們介紹了語音伺服器分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架構如何實現百萬級房間的設計方法，並梳理了語音聊天室的整體架構。希望對大家有所幫助。