日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

1. 引言

大家好，我是小。

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站制作、網(wǎng)站設(shè)計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的昆山網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

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

圖片

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

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

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

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

圖片

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

今天我們就來探討一下。

2. 系統(tǒng)需求

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

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

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

圖片

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

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

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

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

3. 概要設(shè)計

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

3.1 核心組件

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

圖片

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

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

群聊創(chuàng)建

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

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

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

4. 面對面建群

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

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

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

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

圖片

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

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

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

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

圖片

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

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

成員加入，刷新群員信息

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

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

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

其它技術(shù)組件

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

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

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

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

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

5.1 交互流程

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

圖片

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

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

5.2 消息存儲和展示

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

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

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

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

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

6. 搶紅包

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

圖片

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

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

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

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

紅包表 redpack 的字段如下：

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

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

紅包記錄表 redpack_record 如下：

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

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

6.2 實(shí)時性

1、發(fā)紅包

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

2、搶紅包

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

搶紅包的交互步驟如下：

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

6.3 紅包分配算法

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

1、實(shí)時拆分

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

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

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

2、預(yù)先生成

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

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

3、二倍均值法

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

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

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

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

4、算法優(yōu)化

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

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

圖片

無一例外：

圖片

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

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

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

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

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

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

type RedPack struct {    SurplusAmount float64 // 剩余金額    SurplusTotal int // 紅包剩余個數(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,
    }    // 每個紅包先保留 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è)計的產(chǎn)品體驗(yàn)，通過這些核心組件、數(shù)據(jù)庫表和詳細(xì)的交互流程，讓用戶能夠輕松參與并享受群聊系統(tǒng)帶來的便利。

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

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

網(wǎng)站題目：聽說你會架構(gòu)設(shè)計？來，弄一個微信群聊系統(tǒng)
分享路徑：http://www.5511xx.com/article/coohdsj.html