上篇我們介紹了下面這個簡單的語音聊天室的架構，遺留了兩個問題。首先，語音伺服器是怎麼**語音資料的？
我們直接上圖。圖中虛線框表示連線到同一臺語音伺服器。當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部署的概念。本文介紹的都是一些比較基礎的概念，主要為後面的內容做鋪墊。
mysql 聊天室 聊天室php mysql 六
聊天室php mysql 六 相應的 資料庫 phpmyadmin mysql dump 主機 localhost 3306 資料庫 study28 資料表的結構 chat user create table chat user userid varchar 20 not null,passwd v...
聊天室程式
伺服器 include include include include include include include include define servport 8081 伺服器端口號 define bufsize 200 最大傳輸量 int main int args,char argv s...
簡單聊天室
include include include include include include include include include include pthread t thread 2 void send msg void ip msg if connect sockfd,struct ...