十萬用戶規模即時通訊(IM)架構設計
十萬用戶規模即時通訊(IM)架構設計
業務背景
假設你現在正在一個新創公司擔任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.成本問題