1. 引言

大家好，我是小?。

當(dāng)我那天拿著手機(jī)，正在和朋友們的微信群里暢聊著八卦新聞和即將到來(lái)的周末計(jì)劃時(shí)，忽然一條帶著喜意的消息撲面而來(lái)，消息正中間寫著八個(gè)大字：恭喜發(fā)財(cái)，大吉大利。

圖片

搶紅包??！相信大部分人對(duì)此都不陌生，那微信的這個(gè)群聊系統(tǒng)是如何設(shè)計(jì)的，讓我們可以方便地聊天、分享圖片和表情，還有那個(gè)神奇的紅包功能呢？

這個(gè)問題一直困擾著，于是我決定深入了解一下，看看微信的群聊系統(tǒng)背后的設(shè)計(jì)是怎樣的。

微信群聊系統(tǒng)設(shè)計(jì)

微信作為 10 億用戶級(jí)別的全民 App，想必大家都用過，微信建群功能是微信里面核心的一個(gè)能力，它可以將數(shù)百個(gè)好友或陌生人放進(jìn)一個(gè)群空間。

圖片

或許你已經(jīng)在微信上體驗(yàn)過很多次群組聊天，但你是否好奇過這個(gè)背后的系統(tǒng)是如何設(shè)計(jì)的呢？

今天我們就來(lái)探討一下。

2. 系統(tǒng)需求

2.1 系統(tǒng)特點(diǎn)與功能需求

微信群聊功能是社交應(yīng)用的核心功能之一，它允許用戶創(chuàng)建自己的社交圈子，與家人、朋友或共同興趣愛好者進(jìn)行友好地交流。

以下是微信群聊系統(tǒng)的核心功能：

圖片

• 創(chuàng)建群聊：用戶可以創(chuàng)建新的聊天群組，邀請(qǐng)其他好友用戶加入或與陌生人面對(duì)面建群。
• 群組管理：群主和管理員能夠管理群成員，設(shè)置規(guī)則和權(quán)限。
• 消息發(fā)送和接收：允許群成員發(fā)送文本、圖片、音頻、視頻等多種類型的消息，并推送給所有群成員。
• 實(shí)時(shí)通信：消息應(yīng)該能夠快速傳遞，確保實(shí)時(shí)互動(dòng)。
• 搶紅包：用戶在群聊中發(fā)送任意個(gè)數(shù)和金額的紅包，群成員可以搶到隨機(jī)金額的紅包。

2.2 非功能需求：應(yīng)對(duì)高并發(fā)、高性能、海量存儲(chǔ)

當(dāng)我們面對(duì) 10 億微信用戶每天都可能使用建群功能的情景時(shí)，就需要處理大規(guī)模的用戶并發(fā)。這就引出了系統(tǒng)的非功能需求，包括：

• 高并發(fā)：系統(tǒng)需要支持大量用戶同時(shí)創(chuàng)建和使用群組，以確保無(wú)延遲的用戶體驗(yàn)。
• 高性能：快速消息傳遞、即時(shí)響應(yīng)，是數(shù)字社交的關(guān)鍵。
• 海量存儲(chǔ)：系統(tǒng)必須可擴(kuò)展，以容納用戶生成的海量消息文本、圖片及音視頻數(shù)據(jù)。

3. 概要設(shè)計(jì)

在概要設(shè)計(jì)中，我們考慮了系統(tǒng)的核心組件和基本業(yè)務(wù)的概要設(shè)計(jì)。

3.1 核心組件

微信群聊系統(tǒng)中，會(huì)涉及到如下核心組件和協(xié)議。

圖片

• 客戶端：接收手機(jī)或 PC 端微信群聊的消息，并實(shí)時(shí)傳輸給后臺(tái)服務(wù)器
• Websocket傳輸協(xié)議：支持客戶端和后臺(tái)服務(wù)端的實(shí)時(shí)交互，開銷低，實(shí)時(shí)性高，常用于微信、QQ 等 IM 系統(tǒng)通信系統(tǒng)
• 長(zhǎng)連接集群：與客戶端進(jìn)行 Websocket 長(zhǎng)連接的系統(tǒng)集群，并將消息通過中間件轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器
• 消息處理服務(wù)器集群：提供實(shí)時(shí)消息的處理能力，包括數(shù)據(jù)存儲(chǔ)、查詢、與數(shù)據(jù)庫(kù)交互等
• 消息推送服務(wù)器集群：這是信息的中轉(zhuǎn)站，負(fù)責(zé)將消息傳遞給正確的群組成員
• 數(shù)據(jù)庫(kù)服務(wù)器集群：用于存儲(chǔ)用戶文本數(shù)據(jù)、圖片的縮略圖、音視頻元數(shù)據(jù)等
• 分布式文件存儲(chǔ)集群：存儲(chǔ)用戶圖片、音視頻等文件數(shù)據(jù)

3.2 業(yè)務(wù)概要設(shè)計(jì)

群聊創(chuàng)建

• 唯一ID分配：當(dāng)用戶請(qǐng)求創(chuàng)建一個(gè)新群組時(shí)，系統(tǒng)生成一個(gè)唯一的群組 ID，通?？梢允褂梅植际?ID 生成器如雪花算法（Snowflake）或直接使用數(shù)據(jù)庫(kù)自增 ID。這里我們?yōu)榱藢?shí)現(xiàn)簡(jiǎn)便，采用 MySQL 的自增 ID。
• 群組信息存儲(chǔ)：將群組 ID 和相關(guān)信息（例如群名、創(chuàng)建者 ID 等）存儲(chǔ)在群組數(shù)據(jù)庫(kù)中。
• 成員關(guān)聯(lián)：將群主添加為群組的創(chuàng)始成員，同時(shí)創(chuàng)建者也會(huì)成為管理員。
• 消息歷史記錄：為了確保新成員能夠訪問以前的消息，將此新群組的群組 ID 與用戶消息關(guān)聯(lián)存儲(chǔ)。

除了拉好友建群，微信還實(shí)現(xiàn)了面對(duì)面建群的能力。

接下來(lái)，我們深入探討了三到四個(gè)核心功能的詳細(xì)設(shè)計(jì)，包括面對(duì)面建群、消息發(fā)送與接收及搶紅包功能。

4. 面對(duì)面建群

用戶發(fā)起面對(duì)面建群，并輸入一個(gè) 4 位數(shù)的隨機(jī)碼，周圍的用戶輸入該隨機(jī)碼后可加入群聊，面對(duì)面建群功能通常涉及數(shù)據(jù)表設(shè)計(jì)和核心業(yè)務(wù)交互流程如下。

4.1 數(shù)據(jù)庫(kù)表設(shè)計(jì)

1. User 表：存儲(chǔ)用戶信息，包括用戶 ID、昵稱、頭像等。
2. Group 表：存儲(chǔ)群組信息，包括群 ID、群名稱、創(chuàng)建者 ID、群成員個(gè)數(shù)等。
3. GroupMember 表：關(guān)聯(lián)用戶和群組，包括用戶 ID 和群 ID。
4. RandomCode 表：存儲(chǔ)面對(duì)面建群的隨機(jī)碼和關(guān)聯(lián)的群 ID。

4.2 核心業(yè)務(wù)交互流程

圖片

用戶 A 在手機(jī)端應(yīng)用中發(fā)起面對(duì)面建群，并輸入一個(gè)隨機(jī)碼，校驗(yàn)通過后，等待周圍（50 米之內(nèi)）的用戶加入。此時(shí)，系統(tǒng)將用戶信息以 HashMap 的方式存入緩存中，并設(shè)置過期時(shí)間為 3min。

{隨機(jī)碼，用戶列表[用戶A(ID、名稱、頭像)]}

用戶 B 在另一個(gè)手機(jī)端發(fā)起面對(duì)面建群，輸入指定的隨機(jī)碼，如果該用戶周圍有這樣的隨機(jī)碼，則進(jìn)入同一個(gè)群聊等待頁(yè)面，并可以看到其它群?jiǎn)T的頭像和昵稱信息。

此時(shí)，系統(tǒng)除了根據(jù)隨機(jī)碼獲取所有用戶信息，也會(huì)實(shí)時(shí)更新緩存里的用戶信息。

圖片

當(dāng)?shù)谝粋€(gè)用戶點(diǎn)擊進(jìn)入該群時(shí)，就可以加入群聊，系統(tǒng)將生成的隨機(jī)碼保存在 RandomCode 表中，并關(guān)聯(lián)到新創(chuàng)建的群 ID，更新群成員的個(gè)數(shù)。

然后，系統(tǒng)將用戶信息和新生成的群聊信息存儲(chǔ)在 Group、GroupMember 表中

成員加入，刷新群?jiǎn)T信息

之后 B、C 用戶帶著隨機(jī)碼加入群聊時(shí)，手機(jī)客戶端向服務(wù)器后端發(fā)送請(qǐng)求，驗(yàn)證隨機(jī)碼是否有效。服務(wù)器后端驗(yàn)證隨機(jī)碼，檢查隨機(jī)碼是否存在于緩存中，以及是否在有效期內(nèi)。

然后，判斷當(dāng)前群成員是否滿員（目前普通用戶創(chuàng)建的群聊人數(shù)最多為 500 人），如果驗(yàn)證通過，服務(wù)器后端將用戶 B、C 添加到群成員表 GroupMember 中，并返回成功響應(yīng)。

移動(dòng)客戶端應(yīng)用收到成功響應(yīng)后，更新用戶 B、C 的群聊列表，展示他們已加入的新群聊。

其它技術(shù)組件

這樣，用戶 A 通過創(chuàng)建隨機(jī)碼和周圍的用戶掃描二維碼的方式成功建立了一個(gè)面對(duì)面建群。這個(gè)功能涉及了多個(gè)技術(shù)組件，包括分布式緩存、數(shù)據(jù)庫(kù)、二維碼生成和驗(yàn)證等。

同時(shí)，在面對(duì)面建群的過程中相當(dāng)重要的能力是標(biāo)識(shí)用戶的區(qū)域，比如 50 米以內(nèi)。這個(gè)可以用到 Redis 的 GeoHash 算法，來(lái)獲取一個(gè)范圍內(nèi)的所有用戶信息。

由于篇幅有限，這里不展開贅述，想了解更多和二維碼生成及位置算法的細(xì)節(jié)，可以看我之前的文章：聽說你會(huì)架構(gòu)設(shè)計(jì)？來(lái)，弄一個(gè)公交&地鐵乘車系統(tǒng)。

5. 消息發(fā)送與接收

當(dāng)某個(gè)成員在微信群里發(fā)言，系統(tǒng)需要處理消息的分發(fā)、通知其他成員、以及確保消息的顯示。以下是這一功能的詳細(xì)交互步驟，以及數(shù)據(jù)庫(kù)存儲(chǔ)方案。

5.1 交互流程

消息發(fā)送和接收時(shí)序圖如下：

圖片

1. 用戶A在群中發(fā)送一條帶有圖片、視頻或音頻的消息。
2. 移動(dòng)客戶端應(yīng)用將消息內(nèi)容和媒體文件上傳到服務(wù)器后端。
3. 服務(wù)器后端接收到消息和媒體文件后，將消息內(nèi)容存儲(chǔ)到 Message 表中，同時(shí)將媒體文件存儲(chǔ)到分布式文件存儲(chǔ)集群中。在 Message 表里，不僅記錄了媒體文件的 MediaID，以便關(guān)聯(lián)消息和媒體；還記錄了縮略圖、視頻封面圖等等。
4. 服務(wù)器后端會(huì)向所有群成員廣播這條消息。移動(dòng)客戶端應(yīng)用接收到消息后，會(huì)根據(jù)消息類型（文本、圖片、視頻、音頻）加載對(duì)應(yīng)的展示方式。
5. 當(dāng)用戶點(diǎn)擊查看圖片、視頻或音頻縮略圖時(shí)，客戶端應(yīng)用會(huì)根據(jù) MediaID 到對(duì)象存儲(chǔ)集群中獲取對(duì)應(yīng)的媒體文件路徑，并將其展示給用戶。

這個(gè)流程確保了消息和媒體文件的有效存儲(chǔ)和展示。用戶可以上傳和查看各種類型的媒體數(shù)據(jù)，而服務(wù)器后端通過關(guān)聯(lián) Message 和對(duì)象存儲(chǔ)服務(wù)器中的信息，實(shí)現(xiàn)了有效的消息存儲(chǔ)和展示。

5.2 消息存儲(chǔ)和展示

在微信群中保存和展示用戶的圖片、視頻或音頻數(shù)據(jù)，通常需要進(jìn)行數(shù)據(jù)存儲(chǔ)和展示方面的設(shè)計(jì)。除了上面面對(duì)面建群功能中提到的用戶表和群組表以外，還需要以下表結(jié)構(gòu)：

1. Message表： 用于存儲(chǔ)消息，每個(gè)消息都有一個(gè)唯一的 MessageID，消息類型（文本、圖片、視頻、音頻），消息內(nèi)容（文字、圖片縮略圖、視頻封面圖等），發(fā)送者 UserID、接收群 GroupID、發(fā)送時(shí)間等字段。
2. Media表： 存儲(chǔ)用戶上傳的圖片、視頻、音頻等媒體數(shù)據(jù)。每個(gè)媒體文件都有一個(gè)唯一的 MediaID，文件路徑、上傳者 UserID、上傳時(shí)間等字段。
3. MessageState表： 用于存儲(chǔ)用戶消息狀態(tài)，包括 MessageID、用戶 ID、是否已讀等。在消息推送時(shí)，通過這張表計(jì)算未讀數(shù)，統(tǒng)一推送給用戶，并在離線用戶的手機(jī)上展示一個(gè)小數(shù)字代表消息未讀數(shù)。

我們知道，MySQL 每次查詢 select count 類型的語(yǔ)句時(shí)，都會(huì)觸發(fā)全表掃描，所以每次加載消息未讀數(shù)都很慢。

為了查詢性能考慮，我們可以將用戶的消息數(shù)量存入 Redis，并實(shí)時(shí)記錄一個(gè)未讀數(shù)值。并且，當(dāng)未讀數(shù)大于 99 時(shí)，就將未讀數(shù)值置為 100 且不再增加。

當(dāng)推送用戶消息時(shí)，只要未讀數(shù)為 100，就將推送消息數(shù)設(shè)置為 99+，以此來(lái)提升存儲(chǔ)的性能和交互的效率。

6. 搶紅包

搶紅包功能允許用戶在群聊中發(fā)送任意個(gè)數(shù)和金額的紅包，群成員可以搶到隨機(jī)金額的紅包，但要保證每個(gè)用戶的紅包金額不小于 0.01 元。

圖片

搶紅包的詳細(xì)交互流程如下：

1. 用戶接收到搶紅包通知，點(diǎn)擊通知打開群聊頁(yè)面
2. 用戶點(diǎn)擊搶紅包，后臺(tái)服務(wù)驗(yàn)證用戶資格，確保用戶尚未領(lǐng)取過此紅包
3. 若用戶資格驗(yàn)證通過，后臺(tái)服務(wù)分配紅包金額并存儲(chǔ)領(lǐng)取記錄
4. 用戶在微信群中看到領(lǐng)取金額，紅包狀態(tài)更新為“已領(lǐng)取”
5. 異步調(diào)用支付接口，將紅包金額更新到錢包里

搶紅包功能需要關(guān)注搶紅包的數(shù)據(jù)庫(kù)設(shè)計(jì)，搶紅包實(shí)時(shí)性和紅包分配算法。

6.1 數(shù)據(jù)庫(kù)設(shè)計(jì)

紅包表 redpack 的字段如下：

• id： 主鍵，紅包ID
• totalAmount： 總金額
• surplusAmount： 剩余金額
• total： 紅包總數(shù)
• surplusTotal： 剩余紅包總數(shù)
• userId： 發(fā)紅包的用戶ID

該表用來(lái)記錄用戶發(fā)了多少紅包，以及需要維護(hù)的剩余金額。

紅包記錄表 redpack_record 如下：

• id： 主鍵，記錄ID
• redpackId： 紅包ID，外鍵
• userId： 用戶ID
• amount： 搶到的金額

記錄表用來(lái)存放用戶具體搶到的紅包信息，也是紅包表的副表。

6.2 實(shí)時(shí)性

1、發(fā)紅包

1. 用戶設(shè)置紅包的總金額和個(gè)數(shù)后，在紅包表中增加一條數(shù)據(jù)，開始發(fā)紅包
2. 為了保證實(shí)時(shí)性和搶紅包的效率，在 Redis 中增加一條記錄，存儲(chǔ)紅包 ID 和總?cè)藬?shù) n
3. 搶紅包消息推送給所有群成員

2、搶紅包

從 2015 年起，微信紅包的搶紅包和拆紅包就分離了，用戶點(diǎn)擊搶紅包后需要進(jìn)行兩次操作。這也是為什么明明有時(shí)候搶到了紅包，點(diǎn)開后卻發(fā)現(xiàn)該紅包已經(jīng)被領(lǐng)取完了。

搶紅包的交互步驟如下：

1. 搶紅包：搶操作在 Redis 緩存層完成，通過原子遞減的操作來(lái)更新紅包個(gè)數(shù)，到 0 后就說明搶光了。
2. 拆紅包：拆紅包時(shí)，首先會(huì)實(shí)時(shí)計(jì)算金額，一般是通過二倍均值法實(shí)現(xiàn)（即 0.01 到剩余平均值的 2 倍之間）。
3. 紅包記錄：用戶獲取紅包金額后，通過數(shù)據(jù)庫(kù)的事務(wù)操作累加已經(jīng)領(lǐng)取的個(gè)數(shù)和金額，并更新紅包表和記錄表。
4. 轉(zhuǎn)賬：為了提升效率，最終的轉(zhuǎn)賬為異步操作，這也是為什么在春節(jié)期間，紅包領(lǐng)取后不能立即在余額中看到的原因。

6.3 紅包分配算法

紅包金額分配時(shí)，由于是隨機(jī)分配，所以有兩種實(shí)現(xiàn)方案：實(shí)時(shí)拆分和預(yù)先生成。

1、實(shí)時(shí)拆分

實(shí)時(shí)拆分，指的是在搶紅包時(shí)實(shí)時(shí)計(jì)算每個(gè)紅包的金額，以實(shí)現(xiàn)紅包的拆分過程。

這個(gè)需要我們?cè)O(shè)計(jì)一個(gè)好的拆分算法，讓紅包拆分時(shí)一直保證后續(xù)待拆分紅包的金額不能為空。

實(shí)時(shí)拆分時(shí)，不容易做到拆分的紅包金額服從正態(tài)分布規(guī)律。

2、預(yù)先生成

預(yù)先生成，指的是在紅包開搶之前已經(jīng)完成了紅包的金額拆分，搶紅包時(shí)只是依次取出拆分好的紅包金額。

這種方式對(duì)拆分算法要求較低，可以拆分出隨機(jī)性很好的紅包金額，但通常需要結(jié)合隊(duì)列使用，而且需要多設(shè)計(jì)一個(gè)表來(lái)存儲(chǔ)紅包的拆分金額。

3、二倍均值法

綜合上述優(yōu)缺點(diǎn)考慮，以及微信群聊中的人數(shù)不多（目前最高 500 人），所以我們采用實(shí)時(shí)拆分的方式，用二倍均值法來(lái)生成隨機(jī)紅包，只滿足隨機(jī)即可，不需要正態(tài)分布。

故可能出現(xiàn)很大的紅包差額，但這更刺激不是嗎??

使用二倍均值法生成的隨機(jī)數(shù)，每次隨機(jī)金額會(huì)在 0.01 ~ 剩余平均值*2 之間。

假設(shè)當(dāng)前紅包剩余金額為 10 元，剩余個(gè)數(shù)為 5，10/5 = 2，則當(dāng)前用戶可以搶到的紅包金額為：0.01 ~ 4 元之間。

4、算法優(yōu)化

用二倍均值法生成的隨機(jī)紅包雖然接近平均值，但之前我在某論壇上看到過類似的說法：微信紅包金額的隨機(jī)性和領(lǐng)取的時(shí)機(jī)有關(guān)系，尤其是金額不高的情況下。

于是，小?耗費(fèi)巨資在微信群發(fā)了多個(gè)紅包，得出了這樣一個(gè)結(jié)論：如果發(fā)出的 紅包總額 = 紅包數(shù)*0.01 + 0.01，比如：發(fā)了 4 個(gè)紅包，總額為 0.05，則最后一個(gè)人領(lǐng)取的紅包金額一定是 0.02。

圖片

無(wú)一例外：

圖片

所以，紅包金額算法大概率不是隨機(jī)分配，而是在派發(fā)紅包之前已經(jīng)做了處理。比如在紅包金額生成前，先生成一個(gè)不存在的紅包，這個(gè)紅包的總額為 0.01 * 紅包總數(shù)。

而在紅包金額分配的時(shí)候，會(huì)對(duì)每個(gè)紅包的隨機(jī)值基礎(chǔ)上加上 0.01，以此來(lái)保證每個(gè)紅包的最小值不為 0。

所以，假設(shè)用戶發(fā)了總額為 0.04 的個(gè)數(shù)為 3 的紅包時(shí)，需要先提取 3*0.01 到 "第四個(gè)" 不存在的紅包里面，于是第一個(gè)人搶到的紅包隨機(jī)值是 0 ~ (0.04-3*0.01)/3。

由于擔(dān)心紅包超額，所以除數(shù)的商是向下取二位小數(shù)，0 ~ (0.04-3*0.01)/3 ==> (0 ~ 0) = 0，再加上之前提取的保底值 0.01，于是前兩個(gè)搶到的紅包金額都是 0.01。最后一個(gè)紅包的金額為紅包余額，即 0.02。

算法邏輯用 Go 語(yǔ)言實(shí)現(xiàn)如下：

import (
   "fmt"
   "math"
   "math/rand"
   "strconv"
)

type RedPack struct {    SurplusAmount float64 // 剩余金額    SurplusTotal int // 紅包剩余個(gè)數(shù)}

// 取兩位小數(shù)
func remainTwoDecimal(num float64) float64 {    numStr := strconv.FormatFloat(num, 'f', 2, 64)    num, _ = strconv.ParseFloat(numStr, 64)
    return num
}

// 獲取隨機(jī)金額的紅包
func getRandomRedPack(rp *RedPack) float64 {
    if rp.SurplusTotal <= 0 {
        // 該紅包已經(jīng)被搶完了
        return 0
    }

    if rp.SurplusTotal == 1 {
        return remainTwoDecimal(rp.SurplusAmount + 0.01)
    }

       // 向下取整
    avgAmount := math.Floor(100*(rp.SurplusAmount/float64(rp.SurplusTotal))) / float64(100)
    avgAmount = remainTwoDecimal(avgAmount)

       // 生成隨機(jī)數(shù)種子
    rand.NewSource(time.Now().UnixNano())

    var max float64
    if avgAmount > 0 {
        max = 2*avgAmount - 0.01
    } else {
        max = 0
    }
    money := remainTwoDecimal(rand.Float64()*(max) + 0.01)

    rp.SurplusTotal -= 1
    rp.SurplusAmount = remainTwoDecimal(rp.SurplusAmount + 0.01 - money)

    return money
}

func main() {
    rp := &RedPack{
        SurplusAmount: 0.06,
        SurplusTotal:  5,
    }    // 每個(gè)紅包先保留 0.01 的余額
    rp.SurplusAmount -= 0.01 * float64(rp.SurplusTotal)
    total := rp.SurplusTotal
    for i := 0; i < total; i++ {
        fmt.Println(getRandomRedPack(rp))
    }
}

打印結(jié)果：

0.01、0.01、0.01、0.01、0.02

符合預(yù)期！

7. 總結(jié)

微信群聊及搶紅包等功能背后蘊(yùn)藏著復(fù)雜的交互技術(shù)和精心設(shè)計(jì)的產(chǎn)品體驗(yàn)，通過這些核心組件、數(shù)據(jù)庫(kù)表和詳細(xì)的交互流程，讓用戶能夠輕松參與并享受群聊系統(tǒng)帶來(lái)的便利。

并且，添加了這些充滿趣味的功能，也是微信用戶眾多的原因之一吧！

微信建群功能的系統(tǒng)設(shè)計(jì)不僅僅是一個(gè)技術(shù)壯麗的展示，更是數(shù)字社交的魔法之一。