十萬用戶規模即時通訊(IM)架構設計

2023.11.01

十萬用戶規模即時通訊(IM)架構設計

假設每個活躍用戶每天向5位好友發送100條訊息,則訊息數量為:4萬* 5 * 100 = 2000萬,且資料當天基本上都被刪除了,所以寫入、讀取、刪除次數都可以估算為2000萬。

業務背景

假設你現在正在一個新創公司擔任CTO,因為微信工作生活娛樂不區分,已經發生了很多次將敏感資訊(可以自行腦補一下)發錯人甚至發錯群的尷尬事件了!你司CEO 決定做一款IM 工具,為了區別微信和QQ 大眾化的IM 需求,你們公司主打安全IM,這款產品的競爭力如下:主打私密聊天,嚴格控制私密好友的數量,而不是像微信一樣,買菜都可能要加個微信。

【公司背景】

1. 技術團隊大約10個人,後端6個,前端2個,Android 2個,iOS 還沒有;

2. 後端Java 為主,大部分是P6~P7;

3. 後端具備MySQL、微服務、Redis 等開發使用經驗;

4. 後端沒有大數據和推薦相關經驗

業務基本場景

圖片圖片

1. 每個使用者都會透過演算法產生非對稱的公鑰和私鑰;

2. 用戶發送的訊息會透過公鑰加密,接收用戶的訊息使用自己的私鑰解密;

3. 只能建立一對一聊天;

4. 聊天訊息“閱後即焚”,最多只保留60分鐘;

5. 無需使用手機號碼註冊;

6. 每個用戶最多20個好友

總體架構思路

老闆說我們3年內要做到1千萬註冊用戶,身為CTO 的你該如何做架構設計?

十萬:落地快,但是如果業務發展很快,架構很快就不適應了怎麼辦?

百萬:落地慢一些,但同樣面臨業務發展過快的風險。

千萬:落地時間可能要6個月以上,但基本上3年內無需再動架構。

超前設計,架構真的不用動麼?

圖片圖片

1. 業務規模變化

可以超前化設​​計應對。

2. 業務多樣性

無法預測會做什麼功能,業務多樣性會導致團隊人數增加到多少更加無法預測。

3. 技術發展

無法預測,尤其是和法律政策相關的,例如區塊鏈、國產化等。

十萬用戶規模儲存效能估計算

圖片圖片

【註冊】

十萬用戶規模

【登入】

雖然IM 是比較活躍的產品,但由於是全新的產品,我們假設十萬註冊用戶,每天活躍用戶有40%,登入每天4萬。

【加好友】

每位活躍用戶最多20個好友,好友關係數4萬* 20 = 80萬關係數據

【聊天】

假設每個活躍用戶每天向5位好友發送100條訊息,則訊息數量為:4萬* 5 * 100 = 2000萬,且資料當天基本上都被刪除了,所以寫入、讀取、刪除次數都可以估算為2000萬

儲存架構設計

圖片圖片

十萬用戶規模計算效能估算

圖片圖片

【註冊】

1年達到十萬用戶註冊,註冊TPS 很低。

【登入】

雖然IM 是比較活躍的產品,但由於是全新的產品,我們假設十萬註冊用戶,每天活躍用戶有40%,假設登入時間集中在早晚4小時,登入TPS平均值:4萬/ 14400 = 3。

【加好友】

每個活躍用戶最多20個好友,好友關係數4萬* 20 = 80萬數據,依照1年內來計算,TPS 可以忽略不計。

【聊天】

假設每個活躍用戶每天向5位好友發送100條訊息,則訊息數量為:4萬* 5 * 100 = 2000萬;

假設每天集中在早中晚3個時段6小時內(早上1小時中午1小時晚上4小時);

• 傳送訊息TPS:2000萬/(3600*6)≈ 1000;

• 讀取訊息QPS = 發送訊息TPS,刪除訊息TPS ≈ 發送訊息TPS

計算架構之負載平衡

圖片圖片

運算架構之緩存架構

圖片

可擴展架構設計

圖片圖片

高可用架構設計- 同城資料災備

圖片圖片

Redis 儲存的IM 訊息資料為什麼不做跨機房備份?

1.效能問題2.一致性問題3.成本問題