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