上篇我們介紹了下面這個簡單的語音聊天室的架構，遺留了兩個問題。首先，語音服務器是怎么轉發語音數據的？
我們直接上圖。圖中虛線框表示連接到同一台語音服務器。當A說話的時候，客戶端將語音數據上傳到A所連接的語音服務器；語音服務器向房間服務器查詢A所在房間的其他用戶（B-E）所在的語音服務器IP，分幾種情況：對於同服務器用戶B只需要下發語音數據，對於其他服務器上的用戶（C-E）需要轉發給相應的語音服務器，其他語音服務器收到轉發數據后，根據房間信息，下發給同房間的用戶。
有一個細節需要注意，房間服務器是主動給語音服務器同步房間架構的。因為語音服務請求量非常大，如果每次轉發的時候都查詢房間架構信息，那么房間服務器/數據庫將成為瓶頸。因此語音服務器本地緩存了房間架構信息（當然緩存也會導致其他的問題，以后會專門討論）。緩存的同步機制采用用戶進退房主動觸發房間服務器廣播和房間服務器定期推送相結合，這樣可以有效保證網絡丟包情況下的數據一致性。
另外一個問題是目錄服務器是否有點多余？答案自然是否定的。當同一房間用戶量還比較少的情況下，目錄服務器的確可以省略，客戶端可以通過DNS解析域名得到語音服務器的IP地址進行連接。
但是，當用戶量非常大的時候，DNS緩慢的刷新機制不能滿足快速擴容和縮容。目錄服務器還有一個重要的作用是負載均衡，相比DNS手工配置的簡單的負載均衡策略，增加目錄服務器可以實現更加高效的復雜均衡策略。例如下面要介紹的分SET部署。
上圖展示了同一房間的用戶連接語音服務器的兩種分布：對於A-E用戶散落在5台語音服務器，而A’-E’則連接到2台語音服務器。我們覺得，第二種分布更好。為什么？因為服務器數量更少，語音服務器之間的轉發數據量更少。要知道在百萬級甚至千萬級別的語音服務系統中，機器成本和帶寬成本是主要的成本。
如何實現第二種分布呢？這就有賴於目錄服務器的負載均衡策略。其中一條策略是同一房間的用戶優先分配到相同的語音服務器。當然還有其他的一些策略，我們先不展開。
除了通過負載均衡策略實現更聚集的分布以外，還有一種更常用的手段——分SET部署。如圖所示，其實就是增加了一個虛擬SET的概念，一個SET是一個小的服務器集群。SET之間互相隔離，對於小房間（大房間后面再討論），一個房間只能分布在一個SET內。
這樣做有什么好處呢？首先，分SET部署天然可以實現同一房間用戶的聚集分布。一個SET一般是10台語音服務器，如果按照單台能承載2萬用戶來計算，對於房間容量在20萬以下的小房間，同一房間的用戶都分布到一個SET上。其次，分SET部署更便於版本發布和日常運維。試想一下，同樣是有幾百台機器的語音服務器集群，分SET發布更新和不分SET發布更新哪個更容易？
增加SET以后，房間的架構信息增加了SET和房間的映射關系：
SET被賦予一組房間的概念，同一個SET內的房間類型可以多種多樣，但是一般還是把同類型的房間放在一個SET，因為這樣便於管理，發布更新也會比較簡單。通常新擴容一個SET的時候，我們會設置SET的一些屬性，例如這個SET只支持游戲開黑，那后續游戲開黑的新房間就會分配到這個SET。SET的擴容縮容和房間的新建和銷毀我們將在后面的文章中具體介紹。
簡單總結一下，本篇主要解答了上篇文章提到的兩個問題：語音服務器之間是平行轉發數據的；目錄服務器除了有路由的功能還可以實現復雜高效的負載均衡策略。而從目錄服務器的功能又引出了業界常用的分SET部署的概念。本文介紹的都是一些比較基礎的概念，主要為后面的內容做鋪墊。