業務背景

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