語音聊天室怎麼實現呢？網際網路產品設計萬變不離其宗，一套qq的架構設計可以走遍天下。qq群聊是怎麼實現的，那麼把群聊中的文字訊息換成語音資料就是語音聊天室了。
但是實際生產中肯定不會使用這麼簡單的架構，為什麼呢？首先乙個伺服器實現所有功能是不可行的，因為一方面伺服器的效能不可能滿足，另一方面大型軟體的複雜度和維護成本是非常高的，因此軟體工程一直都強調高內聚低耦合，把功能拆解可以使系統更容易維護。
拆解有兩個方向，乙個是按功能拆分，即把不同功能放到不同伺服器完成；另一種是平行擴充套件，即相同功能的服務分布到多台機器上。
首先按功能拆分。按功能拆分又稱為垂直拆分，與平行擴充套件是乙個相對的概念。比較常見的拆分方法是分層，一般分接入層、邏輯層和資料層。接入層是整個系統對外的視窗，除了基本的資料加解密和透傳功能外，還起到保護內部伺服器的作用；邏輯層包含實際的業務伺服器；資料層主要是儲存資料的儲存介質和相關伺服器。
接著是平行擴充套件。為什麼需要平行擴充套件？一方面單機效能有限，即使增加機器配置，效能也是有上限的，因此分布式才是根本解決的方案；另一方面平行擴充套件可以實現服務高可用，即使部分機器宕機，服務仍然可用。
簡單地說，平行擴充套件就是增加備機。而備機有冷熱之分：熱備是指多台機器同時對外提供服務，當其中一台機器故障，其他機器可以正常提供服務；冷備指同時只有一台機器（主機）對外提供服務，其他機器（備機）不提供服務，當主機發生故障時，備機需要切換成主機提供服務。
還有乙個概念，有狀態服務和無狀態服務。網上有很多解釋，大多都比較專業，不再贅述。我只說一下自己的理解，有狀態服務是指本地儲存需要持久化資料的服務，例如資料庫服務；無狀態服務是指本地不儲存持久化資料的服務，例如web伺服器。
有狀態和無狀態一般是跟冷備和熱備對應起來的：有狀態服務使用冷備，無狀態服務使用熱備。這是由它們的特點決定的，有狀態服務因為儲存資料，一般不支援多點寫入，因為資料在伺服器之間同步是非常複雜的（cap理論和paxos演算法了解一下），所以冷備是最簡單的容災策略；無狀態服務不儲存資料，使用者的請求發到哪一台機器都返回一樣的結果，因此所有機器可以同時提供服務。
經過垂直拆分和平行擴充套件，語音聊天室的架構可以分解成下面的形式：
圖中接入層包括目錄伺服器和語音伺服器，邏輯層包括房間伺服器，儲存層包括資料庫。其中接入層和邏輯層服務都是無狀態服務，至少有兩台機器熱備，資料庫一般是主從冷備。
目錄伺服器是使用者訪問系統的地圖，使用者通過它可以找到要連線的伺服器的ip和埠。語音伺服器是處理語音資料上傳和**的服務。房間伺服器維護房間-語音伺服器-使用者的對映關係。對映關係類似下圖，乙個房間的使用者可能分布在多個語音伺服器，另外還有沒有畫出來的關係：乙個語音伺服器上可以有多個房間的使用者。
業務流程如圖所示：使用者a點選進入101聊天室，首先請求目錄伺服器獲得101房間所在語音伺服器的ip列表；然後，a連線某台語音伺服器請求進入101房間。如果進房成功，房間伺服器會把資訊寫入db，使用者a可以在房間開始語音聊天。
這已經是乙個比較完備的系統了。
總結一下，本篇主要介紹了乙個簡單的語音聊天室的設計方案和一些基礎概念。方案設計可以沿著先簡單再完備的思路進行推演。例如最開始的一台伺服器扛不住，就要平行擴充套件，乙個房間的使用者分布到多台伺服器，然後就要有乙個更高層次的伺服器（房間伺服器）提供全域性視野，如此類推。
限於篇幅，上述系統還有很多細節沒有討論。例如語音伺服器是怎麼**語音資料的？目錄伺服器是否有點多餘？等等。我們在接下來的文章中將一一解答，敬請期待。
golang 實現乙個聊天室
最近看了一下go語言，就試著寫了乙個聊天室，練練手而已，但是對於我乙個搞php的來說，go語言對我啟發很大。客服端 package main import fmt net os 定義通道 var ch chan int make chan int 定義暱稱 var nickname string f...
乙個簡單聊天室的建立
經過乙個階段的asp學習,下面我們結合所學過的內容建立乙個最簡單的聊天室,雖然很簡單,但是大家可以通過他來掌握乙個聊天室建立的基本過程,並且可以不斷的完善其功能.下面介紹其主要步驟 3,最後把txtwho的內容初始化.也就是當瀏覽者輸入過一次自己的姓名以後就不用再次輸入了,為了區分每個不同的瀏覽者,...
用WCF建立乙個聊天室
服務端 1 先定義介面 namespace reply 2 實現介面 在雲伺服器部署的時候，需要用內網位址來部署，然後用外網的位址開啟，得到乙個該服務的位址，然後引用到客戶端。客戶端 1 主介面 using system using system.collections.generic using ...