業(yè)務(wù)背景

假設(shè)你現(xiàn)在正在一個創(chuàng)業(yè)公司擔(dān)任 CTO，因為微信工作生活娛樂不區(qū)分，已經(jīng)發(fā)生了很多次將敏感信息（可以自行腦補一下）發(fā)錯人甚至發(fā)錯群的尷尬事件了！你司 CEO 決定做一款 IM 工具，為了區(qū)別微信和 QQ 大眾化的 IM 需求，你們公司主打安全 IM，這款產(chǎn)品的競爭力如下：主打私密聊天，嚴格控制私密好友的數(shù)量，而不是像微信一樣，買個菜都可能要加個微信。

【公司背景】

1. 技術(shù)團隊大約10個人，后端6個，前端2個，Android 2個，iOS 還沒有；

2. 后端 Java 為主，大部分是 P6~P7；

3. 后端具備 MySQL、微服務(wù)、Redis 等開發(fā)使用經(jīng)驗；

4. 后端沒有大數(shù)據(jù)和推薦相關(guān)經(jīng)驗

業(yè)務(wù)基本場景

圖片

1. 每個用戶都會通過算法生成非對稱的公鑰和私鑰；

2. 用戶發(fā)送的消息會通過公鑰加密，接收用戶的消息使用自己的私鑰解密；

3. 只能創(chuàng)建一對一聊天；

4. 聊天消息“閱后即焚”，最多只保留60分鐘；

5. 無需使用手機號注冊；

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

總體架構(gòu)思路

老板說我們3年內(nèi)要做到1千萬注冊用戶，作為 CTO 的你應(yīng)該如何做架構(gòu)設(shè)計？

十萬：落地快，但是如果業(yè)務(wù)發(fā)展很快，架構(gòu)很快不適應(yīng)了怎么辦？

百萬：落地慢一些，但同樣面臨業(yè)務(wù)發(fā)展過快的風(fēng)險。

千萬：落地時間可能要6個月以上，但基本上3年內(nèi)無需再動架構(gòu)。

超前設(shè)計，架構(gòu)真的不用動么？

圖片

1. 業(yè)務(wù)規(guī)模變化

可以超前化設(shè)計應(yīng)對。

2. 業(yè)務(wù)多樣性

無法預(yù)測會做什么功能，業(yè)務(wù)多樣性會導(dǎo)致團隊人數(shù)增多到多少更加無法預(yù)測。

3. 技術(shù)發(fā)展

無法預(yù)測，尤其是和法律政策相關(guān)的，例如區(qū)塊鏈、國產(chǎn)化等。

十萬用戶規(guī)模存儲性能估計算

圖片

【注冊】

十萬用戶規(guī)模

【登錄】

雖然 IM 是比較活躍的產(chǎn)品，但由于是全新的產(chǎn)品，我們假設(shè)十萬注冊用戶，每天活躍用戶有40%，登錄每天4萬。

【加好友】

每個活躍用戶最多20個好友，好友關(guān)系數(shù) 4萬 * 20 = 80萬 關(guān)系數(shù)據(jù)

【聊天】

假設(shè)每個活躍用戶每天向5位好友發(fā)送100條消息，則消息數(shù)量為：4萬 * 5 * 100 = 2000萬，且數(shù)據(jù)當(dāng)天基本都被刪除了，所以寫入、讀取、刪除次數(shù)都可以估算為2000萬

存儲架構(gòu)設(shè)計

圖片

十萬用戶規(guī)模計算性能估算

圖片

【注冊】

1年達到十萬用戶注冊，注冊 TPS 很低。

【登錄】

雖然 IM 是比較活躍的產(chǎn)品，但由于是全新的產(chǎn)品，我們假設(shè)十萬注冊用戶，每天活躍用戶有40%，假設(shè)登錄時間集中在早晚4小時，登錄 TPS均值：4萬 / 14400 = 3。

【加好友】

每個活躍用戶最多20個好友，好友關(guān)系數(shù) 4萬 * 20 = 80萬數(shù)據(jù)，按照1年內(nèi)來計算，TPS 可以忽略不計。

【聊天】

假設(shè)每個活躍用戶每天向5位好友發(fā)送100條消息，則消息數(shù)量為：4萬 * 5 * 100 = 2000萬;

假設(shè)每天集中在早中晚3個時間段6小時內(nèi)（早上1小時中午1小時晚上4小時）；

? 發(fā)送消息 TPS：2000萬/（3600*6）≈ 1000；

? 讀取消息 QPS = 發(fā)送消息 TPS，刪除消息 TPS ≈ 發(fā)送消息 TPS

計算架構(gòu)之負載均衡

圖片

計算架構(gòu)之緩存架構(gòu)

可擴展架構(gòu)設(shè)計

圖片

高可用架構(gòu)設(shè)計 - 同城數(shù)據(jù)災(zāi)備

圖片

Redis 存儲的 IM 消息數(shù)據(jù)為什么不做跨機房備份？

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