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

　　1、大規(guī)模邊緣聊天室如何工作?

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

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

　　每個環(huán)節(jié)都需要額外關注

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

　　2.如何進行聊天室成員狀態(tài)的維護

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

　　3、如何穩(wěn)定超大規(guī)模的連接?

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

　　1.單機負載

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

　　2.集群規(guī)模

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

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

　　4、關鍵：連接承載的瞬時數(shù)量

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

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

　　5、如何進行成員狀態(tài)的維護?

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

　　成員的分級管理

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

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

　　成員的心跳保持

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

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

　　多級路由

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

　　消息推拉結合

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

　　固定路由

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

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

　　7、大規(guī)模邊緣聊天室 VS 中心集群

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

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

　　8、大規(guī)模邊緣聊天室 VS CDN 方式

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

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

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

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

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