當(dāng)前直播成為一種流行趨勢，帶貨直播，網(wǎng)紅帶貨，明星在線演唱會等，進一步使得直播聊天室變成了一個當(dāng)前必備的能力，面向大型，超大型的直播場景，技術(shù)上也在不斷的進行迭代更新。相對于集中式，單中心的方案，不僅僅在服務(wù)的穩(wěn)定性，承載的用戶量級上有了顯著的提升，而且在成本上也能有大幅的降低，同時用戶體驗也變得更好。至于業(yè)界一直嘗試的CDN的聊天室方案同樣存在著本身的局限性，不同于音視頻消息單個內(nèi)容相對較小，瞬時性訪問量較大，重復(fù)訪問的概率幾乎沒有等特定，使得CDN的實踐方案無法滿足該場景的需求。
1、大規(guī)模邊緣聊天室如何工作?
大型邊緣聊天室的工作過程非常的簡單，用戶 UserA 加入聊天室 X，用戶 UserB 也加入聊天室 X，此時用戶 UserA 向聊天室發(fā)送消息 hello,服務(wù)端接收到該消息后，會向 UserA 發(fā)送一個接收成功的回應(yīng)，服務(wù)端同時會將消息進行擴散到所有在同一個聊天室中的人，此示例中為 UserB。
2、場景簡單化但制作不簡單
每個環(huán)節(jié)都需要額外關(guān)注
1.如何穩(wěn)定，高效的保持住百萬甚至千萬的長連接
2.如何進行聊天室成員狀態(tài)的維護
3.如何進行消息路由的選擇
3、如何穩(wěn)定超大規(guī)模的連接?
主要通過兩個方向來解決這個問題，單機的連接數(shù)和集群的規(guī)模。
1.單機負(fù)載
關(guān)于單機連接的提升上，單機的連接數(shù)支撐雖然可以達(dá)到很高的數(shù)值，但是也要考慮是否為有效連接，因為高負(fù)載的連接和低負(fù)載的連接是完全不同的概念，且不說其他的業(yè)務(wù)邏輯，單純其中的心跳保持邏輯，就會造成 CPU 和 IO 非常大的負(fù)擔(dān)，這些還是完全沒有談及業(yè)務(wù)邏輯的基礎(chǔ)上，故而在單機負(fù)載上，一般采用的是不超過 10W 的單機負(fù)載。
2.集群規(guī)模
集群的水平擴展能力決定了集群的規(guī)模，下圖是服務(wù)端的整體部署結(jié)構(gòu)：
上圖中綠色的區(qū)域為負(fù)責(zé)客戶端長連接的區(qū)域，所有的 IMS(IM Server)提供的服務(wù)完全相同，而且相互之間完全沒有任何的依賴關(guān)系;上圖中的黃色是部署在 IDC 中，主要服務(wù)聊天室的路由管理以及消息的路由分發(fā)。IMS 可以認(rèn)為是可以無限水平擴展的架構(gòu)設(shè)計，所以集群的規(guī)?？梢哉J(rèn)為是無限的。集群的規(guī)模上來了，尤其是在邊緣側(cè)的負(fù)載調(diào)度又稱為了一個新問題，基于公司穩(wěn)定而高效的邊緣調(diào)度方式，通過客戶端和服務(wù)端的完美配合實現(xiàn)高效，用戶無感的連接體驗。
4、關(guān)鍵：連接承載的瞬時數(shù)量
對于長連接的場景，連接保持固然重要，連接能夠承載的瞬時數(shù)量也是非常關(guān)鍵的指標(biāo)。而這個點也同樣的是單機和集群的兩個不同維度的問題，集群的角度則和上面的連接保持大致相同，而針對單機的連接創(chuàng)建和斷開，則比單純的保持住連接要復(fù)雜一些，需要考慮到登錄時的鑒權(quán)問題，聊天室的特定場景，還需要考慮退出時的聊天室清理工作。
簡單介紹一下整體的策略，主要將創(chuàng)建和斷開時發(fā)生的事情分成了兩大類，一類是需要同步去執(zhí)行的動作，另外一類是可以進行異步處理的，則放入到異步隊列進行處理。策略本身比較簡單，但是真正在執(zhí)行的過程中能夠做到，而且能夠隨著版本的迭代一直保持策略則顯的比較困難，為了達(dá)到該目標(biāo)，我們堅持著一個原則，凡是要添加到同步邏輯中的內(nèi)容，需要給明相應(yīng)的理由，并且需要團隊內(nèi)部同步討論，否則只能采用異步隊列的方式，這里并不是說異步隊列的事情不需要審核或者討論，而且同步的需要明確的針對性的處理，這樣才能保證同步邏輯的清晰以及策略的可持續(xù)性。
5、如何進行成員狀態(tài)的維護?
聊天室屬于多人聊天的一種特定的形態(tài)，消息僅僅擴散到在線的用戶，用戶離線則自動退出聊天室，并且再次上線后也不會接收到離線時的消息。至于像是一些斷網(wǎng)了重新連接后還能繼續(xù)觀看直播的場景，進去時能夠看到一些歷史消息的情況，則是通過其他的手段實現(xiàn)自動訂閱，拉取歷史的能力。
成員的分級管理
上圖中的左側(cè)為聊天室與用戶直接對應(yīng)的關(guān)系表，也就是圖中的用戶聊天室信息，同步會產(chǎn)生聊天室成員信息，后續(xù)在消息路由的情況下，會高頻的使用該結(jié)構(gòu)查詢聊天室的人員，進一步進行消息的擴散。分層的核心點在于節(jié)點聊天室的維護，只在當(dāng)前節(jié)點的聊天室列表發(fā)生變化時才會修改節(jié)點聊天室信息，并且將該變更同步到 IDC，也即是上一次路由表中。這里只有第一個人加入聊天室和最后一個人退出聊天室時才會觸發(fā)相應(yīng)的邏輯。
上面是進一步抽離了關(guān)于分級注冊的邏輯，由每一級將當(dāng)前層級的聊天室對應(yīng)關(guān)系注冊，?；畹缴弦患壍牧奶焓谊P(guān)系中，我們也僅僅驗證了 3 層，至于更多的層級理論上是可行的，但是不推薦使用，每增加一層復(fù)雜度和對異常情況的處理就會翻倍，對于后續(xù)介紹的消息投遞則必須是所有的層級都正常工作才能將消息正常投遞下來。
成員的心跳保持
本節(jié)點上的聊天室信息由于都是內(nèi)存級別的操作，所以一般出問題的概率比較小。保障其一致性比較簡單，但是跨節(jié)點，尤其是跨機房的，跨地區(qū)的網(wǎng)絡(luò)交互，很難保證每次都是正常的，所以在同步相關(guān)的信息的時候，添加了類似的?；顧C制，異步隊列機制，重試機制等來進一步保障業(yè)務(wù)的穩(wěn)定性，當(dāng)然還有及時異常處理機制，畢竟不能讓用戶進入了聊天室，但是確一直不能接收消息，還不能恢復(fù)當(dāng)前的狀態(tài)。
6、如何進行消息路由的選擇?
多級路由
基于上面的分級注冊的邏輯，可以看出消息的下發(fā)也是分級進行下發(fā)的，這種設(shè)計上減少了每層的下發(fā)的難度，舉個例子如果有 200IMS，10 個 Edge，則極端情況下 IDC 需要分發(fā)的數(shù)量為 10 個，每個 Edge 的分發(fā)數(shù)量為 20 個，如果只有一級的話，則 IDC 需要分發(fā) 200 個請求，這個看著不是一個很大的數(shù)字，但是不要忘記這個僅僅為一條消息的分發(fā)量，而如果有 5000 請求則是 200*5000=1，000，000 則有百萬級別的分發(fā)量，通過分級的方式能夠有效的降低各個層級的復(fù)雜度，同時也能盡量減少跨機房，跨地區(qū)的調(diào)用，進一步降低風(fēng)險。分級分發(fā)雖然帶來了好處，也使得路徑的維護變得相對復(fù)雜很多。
消息推拉結(jié)合
聊天室的場景，大部分場景下是采用直接推送消息的方式。大型的聊天室消息的過濾，篩選以及丟棄的策略的方式也是非常復(fù)雜的問題。至于消息到投遞階段之后，直接推消息給客戶端，這樣消息的即時性確實得到了保證，但是客戶端的情況是不同的，機器的配置不同，機器當(dāng)時的運行狀態(tài)不同，網(wǎng)絡(luò)狀況也是不同的，所以在這種情況，需要支持客戶端能夠根據(jù)自己的情況進行拉取一定數(shù)量的消息，這樣能夠更加靈活的適應(yīng)不同的場景。這些策略雖然說這簡單，但是真正的落實到線上的服務(wù)，還是有很多的細(xì)節(jié)點需要考慮，真正做到穩(wěn)定還是比較困難的，畢竟這種特定的場景期望很好的監(jiān)控也是比較困難的。我們也是先從簡單的固定模式的推拉方式進行處理，后續(xù)根據(jù)具體的情況進行更加細(xì)節(jié)性的調(diào)優(yōu)。
固定路由
針對一些明確大型直播的場景需求，也提供了一種簡單的路由方式，從上述的聊天室路由管理，可以看出出問題的情況還是可能存在的，所以針對已知特別大的聊天室場景，該場景的話，可以認(rèn)為能夠覆蓋到所有的 IMS 服務(wù)，所以聊天室的分級注冊就顯得有點多余，所以聊天室級別的注冊變更為節(jié)點的注冊，依賴系統(tǒng)的服務(wù)注冊發(fā)現(xiàn)默認(rèn)就完成相關(guān)的內(nèi)容，這樣整個事情就變得非常的簡單高效了。
這種方式有其在這種超大型聊天室的優(yōu)勢，也存在其自身的瓶頸點，所以的消息不管是否在本節(jié)點有用戶加入了該聊天室，消息都會投遞到該節(jié)點，故而每個 IMS 都要處理所有的消息，盡管很多的消息是沒有下發(fā)投遞的需求。方案沒有萬能的，所以這兩種處理方式是互補的，并不是互斥的。
7、大規(guī)模邊緣聊天室 VS 中心集群
大規(guī)模邊緣聊天室的方案，相較于傳統(tǒng)的中心集群式的聊天室，從技術(shù)的大的架構(gòu)是沒有本質(zhì)的區(qū)別，依然是多級路由，消息推拉結(jié)合的方式。
不同的點在于部署的形態(tài)不同，而恰恰是這些的不同使得很多東西發(fā)生了變化。大規(guī)模邊緣聊天室的方式，增加了邊緣的連通性，能夠在更加靠近用戶的地方進行就近部署，達(dá)到解決最后五公里的目的。并且能夠利用各個機房的資源，從而達(dá)到百萬，千萬級別甚至更高量級的用戶數(shù)量。大規(guī)模邊緣聊天室的方案在實施的過程中，對成本的降低也起到了關(guān)鍵作用，由于中心機房一般保證可用性和穩(wěn)定性，一般采用的都是 BGP 的網(wǎng)絡(luò)，成本相對邊緣機房的非 BGP 網(wǎng)絡(luò)要貴很多。系統(tǒng)整體可用性的角度，大規(guī)模邊緣聊天室相比于中心集群式的聊天室，對于機房故障的容災(zāi)性更好。當(dāng)然這里主要介紹了大規(guī)模聊天室的優(yōu)點，任何一種方案都不是全能的，有其優(yōu)點就有其自身的劣勢。大規(guī)模邊緣聊天室部署形態(tài)復(fù)雜，對于運維體系的要求相對較高，服務(wù)間網(wǎng)絡(luò)穩(wěn)定性也比較難以保障，所以一般適用于對大規(guī)模的，公開的聊天室，對于比價多精細(xì)玩法的場景，或者小規(guī)模不太適合，反而增加了很多的不確定性。 8、大規(guī)模邊緣聊天室 VS CDN 方式
針對大規(guī)模聊天室，曾考慮過是否可以使用業(yè)界比較成熟的 CDN 分發(fā)技術(shù)。在具體的實踐過程中發(fā)現(xiàn)，針對這種小包，而且不會重復(fù)分發(fā)的場景，這里指的是同一個消息，不太會被一段時間不斷的獲取，聊天室的場景一般是當(dāng)時收到了就收到了，如果沒有收到，后續(xù)也不太期望需要收到消息。而且 CDN 的方案都是將消息聚合后，客戶端定時拉取的方式，消息存在重疊性，延時性等不能滿足客戶的需求。
技術(shù)難度上，加入 1000 萬的聊天室，每 10s 重新刷新一次消息，也有將近 100W 的 QPS 請求，這對于 CDN 系統(tǒng)也是一個非常大的調(diào)整，而且即使接入多家的 CDN 也會存在比較高比例的超時。更何況 10S 的延時，對于有些場景已經(jīng)能夠明顯感知到了。
大規(guī)模聊天室相對于集中式，單中心的方案，不僅僅在服務(wù)的穩(wěn)定性，承載的用戶量級上有了顯著的提升，而且在成本上也能有大幅的降低，同時用戶體驗也變得更好。至于業(yè)界一直嘗試的 CDN 的聊天室方案同樣存在著本身的局限性，不同于音視頻消息單個內(nèi)容相對較小，瞬時性訪問量較大，重復(fù)訪問的概率幾乎沒有等特定，使得 CDN 的實踐方案無法滿足該場景的需求。
8、典型案例：卡特爾世界杯，邊緣網(wǎng)絡(luò)+低時延，支持1800萬用戶同時在線大規(guī)模聊天室，消息下發(fā)每秒4000萬條;
2022卡塔爾世界杯已經(jīng)圓滿落幕，期間，環(huán)信針對運營商客戶對于世界杯的直播聊天室進行專業(yè)改造，并且?guī)椭蛻魧崿F(xiàn)千萬級聊天室的技術(shù)支持。解決了客戶對于世界杯賽事直播海量用戶在線的需求，通過架構(gòu)的調(diào)整，能夠同時支撐1800萬用戶同時在線，消息的處理能力達(dá)到了5000QPS，消息的下發(fā)量達(dá)到了4000萬+/秒的級別。環(huán)信整體方案不僅能夠支持到如此大規(guī)模的量級，而且成本也能夠比肩CDN的方案，機器能夠進行高效的擴縮容。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
