即時通訊系統(tǒng)為什么選擇GaussDB(for Redis)？
每當(dāng)網(wǎng)絡(luò)上爆出熱點(diǎn)新聞，混跡于各個社交媒體的小伙伴們全都開啟了討論模式。一條消息的產(chǎn)生是如何在群聊中傳遞的呢？讓我們一起來探索即時通訊系統(tǒng)(IM)的原理。
IM系統(tǒng)架構(gòu)的原理
當(dāng)你在群聊“相親相愛一家人”中，發(fā)送了一條“我找到女朋友了，今天帶回家吃飯”，你自然是希望全家人都收到你的喜訊，為你女朋友的到來分頭準(zhǔn)備。那么正常的流程應(yīng)該是這樣：遍歷群成員、查詢每個成員的在線狀態(tài)、如果小伙伴們在線則實時進(jìn)行推送，如果小伙伴們不在線則暫存至離線庫待上線后主動拉取。
這種模式就是傳統(tǒng)的IM架構(gòu)，由于發(fā)送成功的消息不會落入離線庫，因此聊天記錄多端漫游無法實現(xiàn)。如果在線用戶推送發(fā)生異常，會導(dǎo)致個別人員丟失關(guān)鍵發(fā)言，錯失重要信息。為了保證消息存儲的可靠性，我們對IM系統(tǒng)架構(gòu)進(jìn)行了優(yōu)化，不管成員是否在線都要先把消息和發(fā)送對象存儲起來，再進(jìn)行推送。流程變成：遍歷群成員、為群聊的每一個人對應(yīng)的消息隊列都存一份消息、查詢每個成員的在線狀態(tài)、對在線成員進(jìn)行推送。這就是所謂的寫擴(kuò)散模型。
這里顯然還存在一個問題，我們向每個小伙伴的消息隊列中都存儲了相同的“我找到女朋友了，今天帶回家吃飯”消息，對磁盤和帶寬造成了很大的浪費(fèi)，這是寫擴(kuò)散的最大弊端。所以我們繼續(xù)優(yōu)化，群消息實體存儲一份，用戶只存消息 ID 索引。流程優(yōu)化為：遍歷群聊的成員、先存一份消息實體、群聊所有人都存一份ID 引用、查詢每個成員的在線狀態(tài)、對在線成員進(jìn)行推送。這就是所謂的讀擴(kuò)散模型。
簡單總結(jié)下：
1.讀擴(kuò)散：讀取操作很重，寫入操作很輕，資源消耗相對小一些。
2.寫擴(kuò)散：讀取操作很輕，寫入操作很重，資源消耗相對大一些。
IM系統(tǒng)架構(gòu)優(yōu)化實踐
接下來，讓我們使用GaussDB(for Redis) 來實現(xiàn)一個簡單的IM應(yīng)用。
§使用GaussDB(for Redis)的List類型實現(xiàn)一個消息隊列，防止發(fā)送端瞬時高流量會壓爆消息處理模塊；
§收到消息后，先生成一個全局唯一ID標(biāo)識該信息，將消息ID和消息內(nèi)容存入String類型的消息存儲庫中，如果消息字段復(fù)雜也可以考慮使用Hash類型；
§對于消息中可索引的信息，將消息的索引信息存入Zset類型的消息索引庫中，這樣無論是接收者還是發(fā)送者，都可以按照一定規(guī)則對歷史消息進(jìn)行檢索；
§通過查詢Set類型的消息關(guān)系群組庫，查詢該信息的接收者集合，這個集合可以根據(jù)一定的規(guī)則動態(tài)增刪；
§將消息ID推入Stream類型的消息同步庫，每個Stream對象對應(yīng)一個接收者，接收者可以通過XRANG命令獲取一個范圍內(nèi)的未讀信息ID；
§最后，接收者再通過這組ID，從消息存儲庫中讀取消息原始內(nèi)容，即完成了一次消息傳遞。
Why GaussDB (for Redis)?
IM系統(tǒng)有哪些痛點(diǎn)？高斯Redis如何解決這些痛點(diǎn)？
1.開源Redsi數(shù)據(jù)庫可靠性差，甚至丟數(shù)據(jù)，會直接導(dǎo)致IM系統(tǒng)癱瘓。
GaussDB(for Redis)對數(shù)據(jù)進(jìn)行分片，在故障場景下可以自動進(jìn)行接管，最多可以滿足N-1個計算節(jié)點(diǎn)故障；存儲層使用華為自研的企業(yè)級存儲池DFV Pool，基于分布式、強(qiáng)一致、高性能的先進(jìn)架構(gòu)，實現(xiàn)3AZ6副本存儲，保證了在任何時間點(diǎn)的數(shù)據(jù)強(qiáng)一致，故障情況下數(shù)據(jù)不丟失。
2.大流量、高并發(fā)場景如何支持連接管理，按業(yè)務(wù)況分散壓力？
GaussDB(for Redis)可以滿足IM系統(tǒng)對可用性的要求，客戶端程序通過ELB接入GaussDB(for Redis)實例，可實現(xiàn)自動負(fù)載均衡。
3.突發(fā)的高流量、大量的歷史消息數(shù)據(jù)如何處理？
GaussDB(for Redis)采用先進(jìn)的存算分離架構(gòu)，在IM系統(tǒng)持續(xù)運(yùn)營的過程中，如果出現(xiàn)突發(fā)流量，可以迅速對計算層資源進(jìn)行秒級擴(kuò)縮容，快速扛住流量尖峰；歷史消息持續(xù)增長時，也可以單獨(dú)對存儲層資源大小進(jìn)行秒級動態(tài)調(diào)整，最高可擴(kuò)容至PB級。
GaussDB(for Redis)廣泛適用于社交媒體、游戲、電商、推薦系統(tǒng)等領(lǐng)域，在海量并發(fā)場景具備極強(qiáng)的高可用能力。如果你需要一款穩(wěn)定可靠的高性能企業(yè)級KV數(shù)據(jù)庫，不妨試試GaussDB(for Redis)。
