網際網路產品後台開發信奉一句話：先扛住再優化。工程師當然是希望把系統設計得盡善盡美，但是業務發展往往是不允許的，因此後台工程師的工作就是在技術和業務之間尋找平衡點。大部分的系統都是逐步迭代演進而來的，沒有一蹴而就的完美系統。
前文中，我們介紹了語音伺服器分set部署的概念。其實一直在迴避乙個問題，分set的缺點是什麼？
分set限制了房間的容量。因為不分set還好，分set了以後乙個房間撐死只能達到20萬的使用者，這樣看起來分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架構如何實現百萬級房間的設計方法，並梳理了語音聊天室的整體架構。希望對大家有所幫助。
百萬級量的資料分頁查詢如何優化？
方法 1 直接使用資料庫提供的 sql 語句 語句樣式 mysql 中,可用如下方法 select from 表名稱 limit m,n 適應場景 適用於資料量較少的情況 元組百 千級 原因 缺點 全表掃瞄,速度會很慢 且 有的資料庫結果集返回不穩定 如某次返 回 1,2,3,另外的一次返回 2,1...
系統通知 聊天服務的實現
使用者資訊用user1 ip1,user2 ip2表示。後面的訊息儲存db是公共的。1 使用者登入時主動拉取資訊，server將該使用者的離線資訊發給使用者 2 同server中，不同使用者傳遞訊息時，server將收到的其他使用者發來的訊息直接儲存並發給該目標使用者 無需判斷傳送是否成功。不成功則...
如何在生產環境刪除百萬級以上的資料
公司的使用者被人惡意註冊了，user id是連續著的，這些使用者現在要清理掉，但是資料量太大，如何快速生成200w的delete語句呢？ps 生產環境不建議delete from user where user id and user id sqlyog環境下快速生成語句 在伺服器上 select ...