當前直播成為一種流行趨勢，帶貨直播，網紅帶貨，明星在線演唱會等，進一步使得直播聊天室變成了一個當前必備的能力，面向大型，超大型的直播場景，技術上也在不斷的進行迭代更新。相對于集中式，單中心的方案，不僅僅在服務的穩定性，承載的用戶量級上有了顯著的提升，而且在成本上也能有大幅的降低，同時用戶體驗也變得更好。至于業界一直嘗試的CDN的聊天室方案同樣存在著本身的局限性，不同于音視頻消息單個內容相對較小，瞬時性訪問量較大，重復訪問的概率幾乎沒有等特定，使得CDN的實踐方案無法滿足該場景的需求。

1、大規模邊緣聊天室如何工作?

大型邊緣聊天室的工作過程非常的簡單，用戶 UserA 加入聊天室 X，用戶 UserB 也加入聊天室 X，此時用戶 UserA 向聊天室發送消息 hello,服務端接收到該消息后，會向 UserA 發送一個接收成功的回應，服務端同時會將消息進行擴散到所有在同一個聊天室中的人，此示例中為 UserB。

2、場景簡單化但制作不簡單

每個環節都需要額外關注

1.如何穩定，高效的保持住百萬甚至千萬的長連接

2.如何進行聊天室成員狀態的維護

3.如何進行消息路由的選擇

3、如何穩定超大規模的連接?

主要通過兩個方向來解決這個問題，單機的連接數和集群的規模。

1.單機負載

關于單機連接的提升上，單機的連接數支撐雖然可以達到很高的數值，但是也要考慮是否為有效連接，因為高負載的連接和低負載的連接是完全不同的概念，且不說其他的業務邏輯，單純其中的心跳保持邏輯，就會造成 CPU 和 IO 非常大的負擔，這些還是完全沒有談及業務邏輯的基礎上，故而在單機負載上，一般采用的是不超過 10W 的單機負載。

2.集群規模

集群的水平擴展能力決定了集群的規模，下圖是服務端的整體部署結構：

上圖中綠色的區域為負責客戶端長連接的區域，所有的 IMS(IM Server)提供的服務完全相同，而且相互之間完全沒有任何的依賴關系;上圖中的黃色是部署在 IDC 中，主要服務聊天室的路由管理以及消息的路由分發。IMS 可以認為是可以無限水平擴展的架構設計，所以集群的規?？梢哉J為是無限的。集群的規模上來了，尤其是在邊緣側的負載調度又稱為了一個新問題，基于公司穩定而高效的邊緣調度方式，通過客戶端和服務端的完美配合實現高效，用戶無感的連接體驗。

4、關鍵：連接承載的瞬時數量

對于長連接的場景，連接保持固然重要，連接能夠承載的瞬時數量也是非常關鍵的指標。而這個點也同樣的是單機和集群的兩個不同維度的問題，集群的角度則和上面的連接保持大致相同，而針對單機的連接創建和斷開，則比單純的保持住連接要復雜一些，需要考慮到登錄時的鑒權問題，聊天室的特定場景，還需要考慮退出時的聊天室清理工作。

簡單介紹一下整體的策略，主要將創建和斷開時發生的事情分成了兩大類，一類是需要同步去執行的動作，另外一類是可以進行異步處理的，則放入到異步隊列進行處理。策略本身比較簡單，但是真正在執行的過程中能夠做到，而且能夠隨著版本的迭代一直保持策略則顯的比較困難，為了達到該目標，我們堅持著一個原則，凡是要添加到同步邏輯中的內容，需要給明相應的理由，并且需要團隊內部同步討論，否則只能采用異步隊列的方式，這里并不是說異步隊列的事情不需要審核或者討論，而且同步的需要明確的針對性的處理，這樣才能保證同步邏輯的清晰以及策略的可持續性。

5、如何進行成員狀態的維護?

聊天室屬于多人聊天的一種特定的形態，消息僅僅擴散到在線的用戶，用戶離線則自動退出聊天室，并且再次上線后也不會接收到離線時的消息。至于像是一些斷網了重新連接后還能繼續觀看直播的場景，進去時能夠看到一些歷史消息的情況，則是通過其他的手段實現自動訂閱，拉取歷史的能力。

成員的分級管理

上圖中的左側為聊天室與用戶直接對應的關系表，也就是圖中的用戶聊天室信息，同步會產生聊天室成員信息，后續在消息路由的情況下，會高頻的使用該結構查詢聊天室的人員，進一步進行消息的擴散。分層的核心點在于節點聊天室的維護，只在當前節點的聊天室列表發生變化時才會修改節點聊天室信息，并且將該變更同步到 IDC，也即是上一次路由表中。這里只有第一個人加入聊天室和最后一個人退出聊天室時才會觸發相應的邏輯。

上面是進一步抽離了關于分級注冊的邏輯，由每一級將當前層級的聊天室對應關系注冊，?；畹缴弦患壍牧奶焓谊P系中，我們也僅僅驗證了 3 層，至于更多的層級理論上是可行的，但是不推薦使用，每增加一層復雜度和對異常情況的處理就會翻倍，對于后續介紹的消息投遞則必須是所有的層級都正常工作才能將消息正常投遞下來。

成員的心跳保持

本節點上的聊天室信息由于都是內存級別的操作，所以一般出問題的概率比較小。保障其一致性比較簡單，但是跨節點，尤其是跨機房的，跨地區的網絡交互，很難保證每次都是正常的，所以在同步相關的信息的時候，添加了類似的?；顧C制，異步隊列機制，重試機制等來進一步保障業務的穩定性，當然還有及時異常處理機制，畢竟不能讓用戶進入了聊天室，但是確一直不能接收消息，還不能恢復當前的狀態。

6、如何進行消息路由的選擇?

多級路由

基于上面的分級注冊的邏輯，可以看出消息的下發也是分級進行下發的，這種設計上減少了每層的下發的難度，舉個例子如果有 200IMS，10 個 Edge，則極端情況下 IDC 需要分發的數量為 10 個，每個 Edge 的分發數量為 20 個，如果只有一級的話，則 IDC 需要分發 200 個請求，這個看著不是一個很大的數字，但是不要忘記這個僅僅為一條消息的分發量，而如果有 5000 請求則是 200*5000=1，000，000 則有百萬級別的分發量，通過分級的方式能夠有效的降低各個層級的復雜度，同時也能盡量減少跨機房，跨地區的調用，進一步降低風險。分級分發雖然帶來了好處，也使得路徑的維護變得相對復雜很多。

消息推拉結合

聊天室的場景，大部分場景下是采用直接推送消息的方式。大型的聊天室消息的過濾，篩選以及丟棄的策略的方式也是非常復雜的問題。至于消息到投遞階段之后，直接推消息給客戶端，這樣消息的即時性確實得到了保證，但是客戶端的情況是不同的，機器的配置不同，機器當時的運行狀態不同，網絡狀況也是不同的，所以在這種情況，需要支持客戶端能夠根據自己的情況進行拉取一定數量的消息，這樣能夠更加靈活的適應不同的場景。這些策略雖然說這簡單，但是真正的落實到線上的服務，還是有很多的細節點需要考慮，真正做到穩定還是比較困難的，畢竟這種特定的場景期望很好的監控也是比較困難的。我們也是先從簡單的固定模式的推拉方式進行處理，后續根據具體的情況進行更加細節性的調優。

固定路由

針對一些明確大型直播的場景需求，也提供了一種簡單的路由方式，從上述的聊天室路由管理，可以看出出問題的情況還是可能存在的，所以針對已知特別大的聊天室場景，該場景的話，可以認為能夠覆蓋到所有的 IMS 服務，所以聊天室的分級注冊就顯得有點多余，所以聊天室級別的注冊變更為節點的注冊，依賴系統的服務注冊發現默認就完成相關的內容，這樣整個事情就變得非常的簡單高效了。

這種方式有其在這種超大型聊天室的優勢，也存在其自身的瓶頸點，所以的消息不管是否在本節點有用戶加入了該聊天室，消息都會投遞到該節點，故而每個 IMS 都要處理所有的消息，盡管很多的消息是沒有下發投遞的需求。方案沒有萬能的，所以這兩種處理方式是互補的，并不是互斥的。

7、大規模邊緣聊天室 VS 中心集群

大規模邊緣聊天室的方案，相較于傳統的中心集群式的聊天室，從技術的大的架構是沒有本質的區別，依然是多級路由，消息推拉結合的方式。

不同的點在于部署的形態不同，而恰恰是這些的不同使得很多東西發生了變化。大規模邊緣聊天室的方式，增加了邊緣的連通性，能夠在更加靠近用戶的地方進行就近部署，達到解決最后五公里的目的。并且能夠利用各個機房的資源，從而達到百萬，千萬級別甚至更高量級的用戶數量。大規模邊緣聊天室的方案在實施的過程中，對成本的降低也起到了關鍵作用，由于中心機房一般保證可用性和穩定性，一般采用的都是 BGP 的網絡，成本相對邊緣機房的非 BGP 網絡要貴很多。系統整體可用性的角度，大規模邊緣聊天室相比于中心集群式的聊天室，對于機房故障的容災性更好。當然這里主要介紹了大規模聊天室的優點，任何一種方案都不是全能的，有其優點就有其自身的劣勢。大規模邊緣聊天室部署形態復雜，對于運維體系的要求相對較高，服務間網絡穩定性也比較難以保障，所以一般適用于對大規模的，公開的聊天室，對于比價多精細玩法的場景，或者小規模不太適合，反而增加了很多的不確定性。

8、大規模邊緣聊天室 VS CDN 方式

針對大規模聊天室，曾考慮過是否可以使用業界比較成熟的 CDN 分發技術。在具體的實踐過程中發現，針對這種小包，而且不會重復分發的場景，這里指的是同一個消息，不太會被一段時間不斷的獲取，聊天室的場景一般是當時收到了就收到了，如果沒有收到，后續也不太期望需要收到消息。而且 CDN 的方案都是將消息聚合后，客戶端定時拉取的方式，消息存在重疊性，延時性等不能滿足客戶的需求。

技術難度上，加入 1000 萬的聊天室，每 10s 重新刷新一次消息，也有將近 100W 的 QPS 請求，這對于 CDN 系統也是一個非常大的調整，而且即使接入多家的 CDN 也會存在比較高比例的超時。更何況 10S 的延時，對于有些場景已經能夠明顯感知到了。

大規模聊天室相對于集中式，單中心的方案，不僅僅在服務的穩定性，承載的用戶量級上有了顯著的提升，而且在成本上也能有大幅的降低，同時用戶體驗也變得更好。至于業界一直嘗試的 CDN 的聊天室方案同樣存在著本身的局限性，不同于音視頻消息單個內容相對較小，瞬時性訪問量較大，重復訪問的概率幾乎沒有等特定，使得 CDN 的實踐方案無法滿足該場景的需求。

8、典型案例：卡特爾世界杯，邊緣網絡+低時延，支持1800萬用戶同時在線大規模聊天室，消息下發每秒4000萬條;

2022卡塔爾世界杯已經圓滿落幕，期間，環信針對運營商客戶對于世界杯的直播聊天室進行專業改造，并且幫助客戶實現千萬級聊天室的技術支持。解決了客戶對于世界杯賽事直播海量用戶在線的需求，通過架構的調整，能夠同時支撐1800萬用戶同時在線，消息的處理能力達到了5000QPS，消息的下發量達到了4000萬+/秒的級別。環信整體方案不僅能夠支持到如此大規模的量級，而且成本也能夠比肩CDN的方案，機器能夠進行高效的擴縮容。