業務背景

假設你現在正在一個新創公司擔任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.成本問題