摘要：揭祕高斯 Redis 在IM場景中的應用。
本文分享自華爲雲社區《華爲雲PB級數據庫GaussDB(for Redis)揭祕第五期：高斯 Redis 在IM場景中的應用》，原文作者：心機胖 。
一、背景
即時通訊（Instant Messaging，簡稱IM）是一個實時通信系統，允許兩人或多人使用網絡實時的傳遞文字消息、文件、語音與視頻。微信、QQ等IM類產品在這個高度信息化的互聯網時代已成爲生活必備品，IM系統中最核心的部分是消息系統，消息系統中最核心的功能是消息的同步、存儲和檢索。
- 消息同步：將消息完整的、快速的從發送方發送至接收方。消息同步系統最重要的衡量指標是消息傳遞的實時性、完整性、順序性以及支撐的消息規模。
- 消息存儲：即消息的持久化，傳統消息系統通常支持消息在接收端的本地存儲，數據基本不具備可靠性。現代消息系統支持消息在雲端存儲，從而實現消息異地查詢：賬號可在任意客戶端登陸查看所有歷史消息。
- 消息檢索：消息一般是文本，所以支持全文檢索也是必備的能力之一。傳統消息系統通常來說基於本地存儲的消息數據來構建索引，支持消息的本地檢索。而現代消息系統支持消息的在線存儲以及存儲過程中構建索引，提供全面的消息檢索功能。
二、IM系統架構設計
上圖爲IM系統的應用場景，可用於聊天，遊戲、智能客服等諸多行業。不同行業對IM系統的成本、性能、可靠性、時延等指標的需求是不同的，架構設計需要進行平衡。接下來將介紹IM系統架構設計所涉及到的一些基本概念。
2.1 傳統架構 vs 現代架構
- 傳統架構
Ø 先同步後存儲。
Ø 在線消息同步和離線消息緩存。
Ø 服務端不會對消息進行持久化，無法支持消息異地查詢。
- 現代架構
Ø 先存儲後同步。
Ø 劃分消息存儲庫與消息同步庫。消息存儲庫用於全量保存所有會話消息，主要用於支持消息異地查詢。消息同步庫，主要用於接收方的多端同步。
Ø 提供消息全文檢索能力。
2.2 讀擴散vs 寫擴散
《2020微信數據報告》指出，截至2020年9月，微信月活躍用戶數爲10.825億，日消息發送次數450億次，日音視頻呼叫成功次數4.1億次。面臨這麼多的消息，如何保證消息傳遞的可靠性、一致性並且有效的降低服務器或者客戶端的壓力是十分具有技術挑戰的。其中，採用何種讀寫模型對IM系統至關重要，這裏介紹兩種模型：讀擴散和寫擴散。
如上圖所示，用戶B與每個聊天的人(A1,A2,A3)都有一個信箱（一種數據結構的抽象，用於存儲消息），B在查看聊天信息時需讀取所有有新消息的信箱。IM系統裏的讀擴散通常是每兩個相關聯的人就有一個信箱。
讀擴散的優點：
- 寫操作(發消息)輕量，不管是單聊還是羣聊，只需要往相應的信箱寫一次即可。
- 每一個信箱天然就是兩個人的聊天記錄，可以方便查看和搜索聊天記錄。
讀擴散的缺點：
- 讀操作(讀消息)很重，存在讀放大效應。
如上圖，在寫擴散中，用戶(B1,B2,B3)都只從自己的信箱裏讀取消息，但寫(發消息)的時候，對於單聊跟羣聊處理如下：
- 單聊：往自己的信箱跟對方的信箱都寫一份消息；同時，如果需要查看兩個人的聊天曆史記錄的話還需要再寫一份。
- 羣聊：發信息時需要針對所有羣成員的信箱都寫一份消息。羣聊使用的是寫擴散模型，而寫擴散很消耗資源，因此微信羣有人數上限(目前是500)。
寫擴散優點：
- 讀操作很輕量，只需要讀取自己的郵箱。
- 可以很方便實現消息的多終端同步。
寫擴散缺點：
- 寫操作很重，尤其是對於羣聊來說。
2.3 推模式 vs 拉模式 vs 推拉結合模式
在IM系統中，消息的獲取通常有三種模式：
- 推模式(Push)：新消息到達時由服務器主動推送給所有客戶端；需要客戶端和服務器建立長連接，實時性很高，對客戶端來說只需要接收處理消息即可；缺點是服務端不知道客戶端處理消息的能力，可能會導致數據積壓。
- 拉模式(Pull)：由前端主動發起拉取消息的請求，爲了保證消息的實時性，一般採用推模式，拉模式一般用於獲取歷史消息；因客戶端拉取新消息的時間間隔不好預設，太短
可能會導致大量的連接拉取不到數據，太長導致數據接收不及時。
- 推拉結合模式：兼顧push和pull兩種模式的優點。新消息來臨時服務器會先推送一個新消息到達的通知給前端，前端接收到通知後就向服務器拉取消息。
三、IM技術挑戰
上圖爲IM系統的總體架構圖，Client雙方通信會經過Server轉發來完成消息傳遞。其核心爲消息存儲庫和消息同步庫。這兩種庫對存儲層的性能有極高的要求。
- 支撐海量數據存儲：對於消息存儲庫來說，如果需要消息永久存儲，則隨着時間的積累，數據規模會越來越大，需存儲庫支持容量無限擴展以應對日益增長的消息數據。
- 低存儲成本：消息數據具有明顯的冷熱特徵，大部分查詢集中在熱數據，冷數據需要一個低成本的存儲方式，否則隨着時間的積累，數據量不斷膨脹，存儲成本會不斷上升。
- 數據生命週期管理：不管是對於消息數據的存儲還是同步，數據都需要定義生命週期。存儲庫是用於在線存儲消息數據本身，通常需要設定一個較長週期的保存時間。而同步庫 是用於寫擴散模式的在線或離線推送，通常設定一個較短的保存時間。
- 極高的寫入吞吐：絕大部分IM類場景，通常是採用寫擴散模型，寫擴散要求底層存儲具備極高的寫入吞吐能力，從而應對消息洪峯。
- 低延遲的讀：消息系統通常應用於在線場景，具備較高的實時性，讀取延遲應儘可能低。
四、高斯Redis在IM場景中的優勢
IM系統的核心是存儲層，其性能差異將直接影響IM系統的用戶體驗。目前存儲層可選擇的數據庫產品有很多，如HBase、開源Redis等等。選擇何種數據庫，需根據業務規模、成本、性能等指標來進行綜合選擇。這裏介紹一種NoSQL數據庫：高斯Redis，在性能和規模上，可以滿足IM系統對存儲層的嚴格要求：海量數據存儲、低存儲成本、生命週期管理、寫入吞吐大、讀取時延低。
4.1高斯Redis簡介
高斯Redis是華爲雲數據庫團隊自主研發且兼容Redis5.0協議的雲原生數據庫，採用計算存儲分離架構。存儲側使用自研的存儲系統，容量無限擴展、強一致、高可靠。計算側基於 LSM 存儲引擎實現，通過將大量的隨機寫轉換爲順序寫，從而極大的提升了數據寫入性能，同時也通過讀緩存、bloom filter 等極大優化了讀取性能。下圖是高斯Redis在IM場景的優勢介紹。
4.2基於高斯Redis的IM應用案例：
下圖是基於高斯Redis的IM系統模型圖，這裏我們使用stream作爲基本數據結構。Redis stream不僅可以作爲消息存儲容器，還實現了生產者、消費者等基本模型，具有IM系統的基本功能，如消息訂閱，分發、增加消費者等，用戶可基於高斯Redis快速構建一套IM系統。創建一個羣聊時，在Redis中對應地爲該羣聊創建一個stream隊列。在發送消息時，每個用戶都將消息按照時間順序添加到stream隊列中，保證了消息的有序性。stream是一個持久化的隊列，可保證信息不丟失。
五、總結
高斯Redis通過一系列技術創新實現了讀寫性能水平擴展，秒級擴容，低成本以及自動備份等功能, 可作爲IM系統的存儲層，其優異的讀寫性能和高級特性將會極大助力IM應用.同時，高斯Redis在開源Redis的基礎之上，較好平衡了性能和成本，能夠廣泛應用在智慧醫療、流量削峯、計數器等領域。
六、結束
本文作者：華爲雲高斯Redis團隊。
杭州西安深圳簡歷投遞：[email protected]
更多技術文章，關注高斯Redis官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813
七、參考資料
1. 《GaussDB(for Redis)官方主頁》
https://www.huaweicloud.com/product/gaussdbforredis.html
2. 《華爲雲GaussDB(for Redis)與自建開源Redis的成本對比》
https://www.modb.pro/db/42739
3. 《華爲雲PB級數據庫GaussDB(for Redis)揭祕第一期：Redis與存算分離》
https://bbs.huaweicloud.com/blogs/238584
4. 《華爲雲PB級數據庫GaussDB(for Redis)揭祕第三期：一場由fork引發的超時，讓我們重新探討了Redis的抖動問題》
https://bbs.huaweicloud.com/blogs/245651
5. 《現代 IM 系統中的消息系統架構—架構篇》
https://www.infoq.cn/article/ypb3y2lv-dsftrr5cguv