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

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

大型邊緣聊天室的工作過(guò)程非常的簡(jiǎn)單，用戶 UserA 加入聊天室 X，用戶 UserB 也加入聊天室 X，此時(shí)用戶 UserA 向聊天室發(fā)送消息 hello,服務(wù)端接收到該消息后，會(huì)向 UserA 發(fā)送一個(gè)接收成功的回應(yīng)，服務(wù)端同時(shí)會(huì)將消息進(jìn)行擴(kuò)散到所有在同一個(gè)聊天室中的人，此示例中為 UserB。

2、場(chǎng)景簡(jiǎn)單化但制作不簡(jiǎn)單

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

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

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

3.如何進(jìn)行消息路由的選擇

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

主要通過(guò)兩個(gè)方向來(lái)解決這個(gè)問(wèn)題，單機(jī)的連接數(shù)和集群的規(guī)模。

1.單機(jī)負(fù)載

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

2.集群規(guī)模

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

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

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

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

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

5、如何進(jìn)行成員狀態(tài)的維護(hù)?

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

成員的分級(jí)管理

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

上面是進(jìn)一步抽離了關(guān)于分級(jí)注冊(cè)的邏輯，由每一級(jí)將當(dāng)前層級(jí)的聊天室對(duì)應(yīng)關(guān)系注冊(cè)，?；畹缴弦患?jí)的聊天室關(guān)系中，我們也僅僅驗(yàn)證了 3 層，至于更多的層級(jí)理論上是可行的，但是不推薦使用，每增加一層復(fù)雜度和對(duì)異常情況的處理就會(huì)翻倍，對(duì)于后續(xù)介紹的消息投遞則必須是所有的層級(jí)都正常工作才能將消息正常投遞下來(lái)。

成員的心跳保持

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

6、如何進(jìn)行消息路由的選擇?

多級(jí)路由

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

消息推拉結(jié)合

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

固定路由

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

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

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

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

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

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

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

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

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

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

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。 ）