每當(dāng)網(wǎng)絡(luò)上爆出熱點(diǎn)新聞，混跡于各個(gè)社交媒體的小伙伴們?nèi)奸_(kāi)啟了討論模式。一條消息的產(chǎn)生是如何在群聊中傳遞的呢？讓我們一起來(lái)探索即時(shí)通訊系統(tǒng)(IM)的原理。

IM 系統(tǒng)架構(gòu)的原理

當(dāng)你在群聊“相親相愛(ài)一家人”中，發(fā)送了一條“我找到女朋友了，今天帶回家吃飯”，你自然是希望全家人都收到你的喜訊，為你女朋友的到來(lái)分頭準(zhǔn)備。那么正常的流程應(yīng)該是這樣：遍歷群成員、查詢(xún)每個(gè)成員的在線(xiàn)狀態(tài)、如果小伙伴們?cè)诰€(xiàn)則實(shí)時(shí)進(jìn)行推送，如果小伙伴們不在線(xiàn)則暫存至離線(xiàn)庫(kù)待上線(xiàn)后主動(dòng)拉取。

這種模式就是傳統(tǒng)的 IM 架構(gòu)，由于發(fā)送成功的消息不會(huì)落入離線(xiàn)庫(kù)，因此聊天記錄多端漫游無(wú)法實(shí)現(xiàn)。如果在線(xiàn)用戶(hù)推送發(fā)生異常，會(huì)導(dǎo)致個(gè)別人員丟失關(guān)鍵發(fā)言，錯(cuò)失重要信息。為了保證消息存儲(chǔ)的可靠性，我們對(duì) IM 系統(tǒng)架構(gòu)進(jìn)行了優(yōu)化，不管成員是否在線(xiàn)都要先把消息和發(fā)送對(duì)象存儲(chǔ)起來(lái)，再進(jìn)行推送。流程變成：遍歷群成員、為群聊的每一個(gè)人對(duì)應(yīng)的消息隊(duì)列都存一份消息、查詢(xún)每個(gè)成員的在線(xiàn)狀態(tài)、對(duì)在線(xiàn)成員進(jìn)行推送。這就是所謂的寫(xiě)擴(kuò)散模型。

這里顯然還存在一個(gè)問(wèn)題，我們向每個(gè)小伙伴的消息隊(duì)列中都存儲(chǔ)了相同的“我找到女朋友了，今天帶回家吃飯”消息，對(duì)磁盤(pán)和帶寬造成了很大的浪費(fèi)，這是寫(xiě)擴(kuò)散的最大弊端。所以我們繼續(xù)優(yōu)化，群消息實(shí)體存儲(chǔ)一份，用戶(hù)只存消息ID索引。流程優(yōu)化為：遍歷群聊的成員、先存一份消息實(shí)體、群聊所有人都存一份 ID引用、查詢(xún)每個(gè)成員的在線(xiàn)狀態(tài)、對(duì)在線(xiàn)成員進(jìn)行推送。這就是所謂的讀擴(kuò)散模型。

簡(jiǎn)單總結(jié)下：

1.讀擴(kuò)散：讀取操作很重，寫(xiě)入操作很輕，資源消耗相對(duì)小一些。

2.寫(xiě)擴(kuò)散：讀取操作很輕，寫(xiě)入操作很重，資源消耗相對(duì)大一些。

IM 系統(tǒng)架構(gòu)優(yōu)化實(shí)踐

接下來(lái)，讓我們使用 GaussDB(forRedis)來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 IM 應(yīng)用。

使用 GaussDB(forRedis)的 List 類(lèi)型實(shí)現(xiàn)一個(gè)消息隊(duì)列，防止發(fā)送端瞬時(shí)高流量會(huì)壓爆消息處理模塊；

收到消息后，先生成一個(gè)全局唯一 ID 標(biāo)識(shí)該信息，將消息 ID 和消息內(nèi)容存入 String 類(lèi)型的消息存儲(chǔ)庫(kù)中，如果消息字段復(fù)雜也可以考慮使用 Hash 類(lèi)型；

對(duì)于消息中可索引的信息，將消息的索引信息存入 Zset 類(lèi)型的消息索引庫(kù)中，這樣無(wú)論是接收者還是發(fā)送者，都可以按照一定規(guī)則對(duì)歷史消息進(jìn)行檢索；

通過(guò)查詢(xún) Set 類(lèi)型的消息關(guān)系群組庫(kù)，查詢(xún)?cè)撔畔⒌慕邮照呒希@個(gè)集合可以根據(jù)一定的規(guī)則動(dòng)態(tài)增刪；

將消息 ID 推入 Stream 類(lèi)型的消息同步庫(kù)，每個(gè) Stream 對(duì)象對(duì)應(yīng)一個(gè)接收者，接收者可以通過(guò) XRANG 命令獲取一個(gè)范圍內(nèi)的未讀信息 ID；

最后，接收者再通過(guò)這組 ID，從消息存儲(chǔ)庫(kù)中讀取消息原始內(nèi)容，即完成了一次消息傳遞。

WhyGaussDB(forRedis)?

IM 系統(tǒng)有哪些痛點(diǎn)？高斯 Redis 如何解決這些痛點(diǎn)？

開(kāi)源 Redsi 數(shù)據(jù)庫(kù)可靠性差，甚至丟數(shù)據(jù)，會(huì)直接導(dǎo)致 IM 系統(tǒng)癱瘓。

GaussDB(forRedis)對(duì)數(shù)據(jù)進(jìn)行分片，在故障場(chǎng)景下可以自動(dòng)進(jìn)行接管，最多可以滿(mǎn)足 N-1 個(gè)計(jì)算節(jié)點(diǎn)故障；存儲(chǔ)層使用華為自研的企業(yè)級(jí)存儲(chǔ)池 DFVPool，基于分布式、強(qiáng)一致、高性能的先進(jìn)架構(gòu)，實(shí)現(xiàn) 3AZ6 副本存儲(chǔ)，保證了在任何時(shí)間點(diǎn)的數(shù)據(jù)強(qiáng)一致，故障情況下數(shù)據(jù)不丟失。

大流量、高并發(fā)場(chǎng)景如何支持連接管理，按業(yè)務(wù)況分散壓力？

GaussDB(forRedis)可以滿(mǎn)足 IM 系統(tǒng)對(duì)可用性的要求，客戶(hù)端程序通過(guò) ELB 接入 GaussDB(forRedis)實(shí)例，可實(shí)現(xiàn)自動(dòng)負(fù)載均衡。

突發(fā)的高流量、大量的歷史消息數(shù)據(jù)如何處理？

GaussDB(forRedis)采用先進(jìn)的存算分離架構(gòu)，在 IM 系統(tǒng)持續(xù)運(yùn)營(yíng)的過(guò)程中，如果出現(xiàn)突發(fā)流量，可以迅速對(duì)計(jì)算層資源進(jìn)行秒級(jí)擴(kuò)縮容，快速扛住流量尖峰；歷史消息持續(xù)增長(zhǎng)時(shí)，也可以單獨(dú)對(duì)存儲(chǔ)層資源大小進(jìn)行秒級(jí)動(dòng)態(tài)調(diào)整，最高可擴(kuò)容至 PB 級(jí)。

GaussDB(forRedis)廣泛適用于社交媒體、游戲、電商、推薦系統(tǒng)等領(lǐng)域，在海量并發(fā)場(chǎng)景具備極強(qiáng)的高可用能力。如果你需要一款穩(wěn)定可靠的高性能企業(yè)級(jí) KV 數(shù)據(jù)庫(kù)，不妨試試 GaussDB(forRedis)。

審核編輯黃宇