新聞中心
大家好,我是小,一個漂泊江湖多年的 985 非科班程序員,曾混跡于國企、互聯(lián)網(wǎng)大廠和創(chuàng)業(yè)公司的后臺開發(fā)攻城獅。

成都創(chuàng)新互聯(lián)公司是一家專注于做網(wǎng)站、網(wǎng)站設(shè)計與策劃設(shè)計,太白網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設(shè)10年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:太白等地區(qū)。太白做網(wǎng)站價格咨詢:13518219792
1. 引言
前些天所在部門出去團(tuán)建,于是公司行政和 HR 拉了一個微信群,發(fā)布一些跟團(tuán)和集合信息。
當(dāng)我正在查看途徑路線和團(tuán)建行程時,忽然一條帶著喜意的消息撲面而來,消息上赫然帶著八個大字:恭喜發(fā)財,大吉大利。
圖片
搶紅包??!原來是公司領(lǐng)導(dǎo)在群里發(fā)了個紅包,于是引得群員哄搶,氣氛其樂融融。
畢竟,團(tuán)不團(tuán)建無所謂,不上班就很快樂;搶多搶少無所謂,有錢進(jìn)就很開心。
打工人果然是最容易滿足的生物!手動狗頭 >
我看著群里嬉戲打鬧的聊天,心中陷入了沉思:微信這個集齊了陌生人聊天、文件分享和搶紅包功能的群聊設(shè)計確實有點意思,如果在面試或者工作中讓我們設(shè)計一個群聊系統(tǒng),需要從哪些方面來考慮呢?
群聊系統(tǒng)設(shè)計
面試官:微信作為 10 億用戶級別的全民 App,有用過吧?
我:(內(nèi)心 OS,說沒用過你也不會相信啊~)當(dāng)然,親愛的面試官,我經(jīng)常使用微信來接收工作消息和文件,并且經(jīng)常在上面處理工作內(nèi)容。
面試官:(內(nèi)心 OS:這小伙子工作意識很強(qiáng)嘛,加分?。㎡K,微信的群聊功能是微信里面核心的一個能力,它可以將數(shù)百個好友或陌生人放進(jìn)一個群空間,如果讓你設(shè)計一個用戶量為 10 億用戶的群聊系統(tǒng),你會怎么設(shè)計呢?
2. 系統(tǒng)需求
2.1 系統(tǒng)特點與功能需求
我:首先群聊功能是社交應(yīng)用的核心能力之一,它允許用戶創(chuàng)建自己的社交圈子,與家人、朋友或共同興趣愛好者進(jìn)行友好地交流。
以下是群聊系統(tǒng)常見的幾個功能:
圖片
- 創(chuàng)建群聊:用戶可以創(chuàng)建新的聊天群組,邀請其他好友用戶加入或與陌生人面對面建群。
- 群組管理:群主和管理員能夠管理群成員,設(shè)置規(guī)則和權(quán)限。
- 消息發(fā)送和接收:允許群成員發(fā)送文本、圖片、音頻、視頻等多種類型的消息,并推送給所有群成員。
- 實時通信:消息應(yīng)該能夠快速傳遞,確保實時互動。
- 搶紅包:用戶在群聊中發(fā)送任意個數(shù)和金額的紅包,群成員可以搶到隨機(jī)金額的紅包。
2.2 非功能需求
除了功能需要,當(dāng)我們面對 10 億微信用戶每天都可能使用建群功能的情景時,還需要處理大規(guī)模的用戶并發(fā)。
這就引出了系統(tǒng)的非功能需求,包括:
- 高并發(fā):系統(tǒng)需要支持大量用戶同時創(chuàng)建和使用群組,以確保無延遲的用戶體驗。
- 高性能:快速消息傳遞、即時響應(yīng),是數(shù)字社交的關(guān)鍵。
- 海量存儲:系統(tǒng)必須可擴(kuò)展,以容納用戶生成的海量消息文本、圖片及音視頻數(shù)據(jù)。
面試官:嗯,不錯,那你可以簡要概述一下這幾個常用的功能嗎?
3. 核心組件
我:好的,我們首先做系統(tǒng)的概要設(shè)計,這里涉及到群聊系統(tǒng)的核心組件和基本業(yè)務(wù)的概要說明。
3.1 核心組件
群聊系統(tǒng)中,會涉及到如下核心組件和協(xié)議。
圖片
- 客戶端:接收手機(jī)或 PC 端微信群聊的消息,并實時傳輸給后臺服務(wù)器;
- Websocket傳輸協(xié)議:支持客戶端和后臺服務(wù)端的實時交互,開銷低,實時性高,常用于微信、QQ 等 IM 系統(tǒng)通信系統(tǒng);
- 長連接集群:與客戶端進(jìn)行 Websocket 長連接的系統(tǒng)集群,并將消息通過中間件轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器;
- 消息處理服務(wù)器集群:提供實時消息的處理能力,包括數(shù)據(jù)存儲、查詢、與數(shù)據(jù)庫交互等;
- 消息推送服務(wù)器集群:這是信息的中轉(zhuǎn)站,負(fù)責(zé)將消息傳遞給正確的群組成員;
- 數(shù)據(jù)庫服務(wù)器集群:用于存儲用戶文本數(shù)據(jù)、圖片的縮略圖、音視頻元數(shù)據(jù)等;
- 分布式文件存儲集群:存儲用戶圖片、音視頻等文件數(shù)據(jù)。
3.2 業(yè)務(wù)概要說明
在業(yè)務(wù)概要說明里,我們關(guān)注用戶的交互方式和數(shù)據(jù)存儲......
面試官:稍等一下,群聊系統(tǒng)的好友建群功能比較簡單,拉好友列表存數(shù)據(jù)就可以了!你用過面對面建群吧,可以簡要說一下如何設(shè)計面對面建群功能嗎?
我:(內(nèi)心 OS,還好之前在吃飯時用過面對面建群結(jié)賬,不然就G了),好的,群聊系統(tǒng)除了拉好友建群外,還支持面對面建群的能力。
4. 面對面建群
用戶發(fā)起面對面建群后,系統(tǒng)支持輸入一個 4 位數(shù)的隨機(jī)碼,周圍的用戶輸入同一個隨機(jī)碼便可加入同一個群聊,面對面建群功能通常涉及數(shù)據(jù)表設(shè)計和核心業(yè)務(wù)交互流程如下。
4.1 數(shù)據(jù)庫表設(shè)計
- User 表:存儲用戶信息,包括用戶 ID、昵稱、頭像等。
- Group 表:存儲群組信息,包括群 ID、群名稱、創(chuàng)建者 ID、群成員個數(shù)等。
- GroupMember 表:關(guān)聯(lián)用戶和群組,包括用戶 ID 和群 ID。
- RandomCode 表:存儲面對面建群的隨機(jī)碼和關(guān)聯(lián)的群 ID。
4.2 核心業(yè)務(wù)交互流程
圖片
用戶 A 在手機(jī)端應(yīng)用中發(fā)起面對面建群,并輸入一個隨機(jī)碼,校驗通過后,等待周圍(50 米之內(nèi))的用戶加入。此時,系統(tǒng)將用戶信息以 HashMap 的方式存入緩存中,并設(shè)置過期時間為 3min。
{隨機(jī)碼,用戶列表[用戶A(ID、名稱、頭像)]}用戶 B 在另一個手機(jī)端發(fā)起面對面建群,輸入指定的隨機(jī)碼,如果該用戶周圍有這樣的隨機(jī)碼,則進(jìn)入同一個群聊等待頁面,并可以看到其它群員的頭像和昵稱信息。
此時,系統(tǒng)除了根據(jù)隨機(jī)碼獲取所有用戶信息,也會實時更新緩存里的用戶信息。
圖片
成員A進(jìn)群
當(dāng)?shù)谝粋€用戶點擊進(jìn)入該群時,就可以加入群聊,系統(tǒng)將生成的隨機(jī)碼保存在 RandomCode 表中,并關(guān)聯(lián)到新創(chuàng)建的群 ID,更新群成員的個數(shù)。
然后,系統(tǒng)將用戶信息和新生成的群聊信息存儲在 Group、GroupMember 表中,并實時更新群成員個數(shù)。
成員B加入
然后,B 用戶帶著隨機(jī)碼加入群聊時,手機(jī)客戶端向服務(wù)器后端發(fā)送請求,驗證隨機(jī)碼是否有效。后臺服務(wù)檢查隨機(jī)碼是否存在于緩存中,如果存在,則校驗通過。
然后,根據(jù) Group 中的成員個數(shù),來判斷當(dāng)前群成員是否滿員(目前普通用戶創(chuàng)建的群聊人數(shù)最多為 500 人)。
如果驗證通過,后臺將用戶 B 添加到群成員表 GroupMember 中,并返回成功響應(yīng)。
面試官:如果有多個用戶同時加入,MySQL 數(shù)據(jù)庫如何保證群成員不會超過最大值呢?
我:有兩種方式可以解決。一個是通過 MySQL 的事務(wù),將獲取 Group 群成員數(shù)和插入 GroupMember 表操作放在同一個事務(wù)里,但是這樣可能帶來鎖表的問題,性能較差。
另一種方式是采用 Redis 的原子性命令incr 來記錄群聊的個數(shù),其中 key 為群聊ID,value 為當(dāng)前群成員個數(shù)。
當(dāng)新增群員時,首先將該群聊的人數(shù)通過 incr 命令加一,然后獲取群成員個數(shù)。如果群員個數(shù)大于最大值,則減一后返回群成員已滿的提示。
使用 Redis 的好處是可以快速響應(yīng),并且可以利用 Redis 的原子特性避免并發(fā)問題,在電商系統(tǒng)中也常常使用類似的策略來防止超賣問題。
位置算法
同時,在面對面建群的過程中相當(dāng)重要的能力是標(biāo)識用戶的區(qū)域,比如 50 米以內(nèi)。這個可以用到 Redis 的 GeoHash 算法,來獲取一個范圍內(nèi)的所有用戶信息。
由于篇幅有限,這里不展開贅述,想了解更多位置算法相關(guān)的細(xì)節(jié),可以看我之前的文章:聽說你會架構(gòu)設(shè)計?來,弄一個公交&地鐵乘車系統(tǒng)。
面試官:嗯不錯,那你再講一下群聊系統(tǒng)里的消息發(fā)送和接收吧!
5. 消息發(fā)送與接收
我:當(dāng)某個成員在微信群里發(fā)言,系統(tǒng)需要處理消息的分發(fā)、通知其他成員、以及確保消息的顯示。
在群聊系統(tǒng)中保存和展示用戶的圖片、視頻或音頻數(shù)據(jù)時,通常需要將元數(shù)據(jù)和文件分開存儲。
其中元數(shù)據(jù)存儲在 MySQL 集群,文件數(shù)據(jù)存儲在分布式對象存儲集群中。
5.1 交互流程
消息發(fā)送和接收的時序圖如下所示:
圖片
- 用戶A在群中發(fā)送一條帶有圖片、視頻或音頻的消息。
- 移動客戶端應(yīng)用將消息內(nèi)容和媒體文件上傳到服務(wù)器后端。
- 服務(wù)器后端接收到消息和媒體文件后,將消息內(nèi)容存儲到 Message 表中,同時將媒體文件存儲到分布式文件存儲集群中。在 Message 表里,不僅記錄了媒體文件的 MediaID,以便關(guān)聯(lián)消息和媒體;還記錄了縮略圖、視頻封面圖等等。
- 服務(wù)器后端會向所有群成員廣播這條消息。移動客戶端應(yīng)用接收到消息后,會根據(jù)消息類型(文本、圖片、視頻、音頻)加載對應(yīng)的展示方式。
- 當(dāng)用戶點擊查看圖片、視頻或音頻縮略圖時,客戶端應(yīng)用會根據(jù) MediaID 到對象存儲集群中獲取對應(yīng)的媒體文件路徑,并將其展示給用戶。
5.2 消息存儲和展示
除了上述建群功能中提到的用戶表和群組表以外,存儲元數(shù)據(jù)還需要以下表結(jié)構(gòu):
- Message表: 用于存儲消息,每個消息都有一個唯一的 MessageID,消息類型(文本、圖片、視頻、音頻),消息內(nèi)容(文字、圖片縮略圖、視頻封面圖等),發(fā)送者 UserID、接收群 GroupID、發(fā)送時間等字段。
- Media表: 存儲用戶上傳的圖片、視頻、音頻等媒體數(shù)據(jù)。每個媒體文件都有一個唯一的 MediaID,文件路徑、上傳者 UserID、上傳時間等字段。
- MessageState表: 用于存儲用戶消息狀態(tài),包括 MessageID、用戶 ID、是否已讀等。在消息推送時,通過這張表計算未讀數(shù),統(tǒng)一推送給用戶,并在離線用戶的手機(jī)上展示一個小數(shù)字代表消息未讀數(shù)。
面試官:我們時??吹饺毫挠?n 個未讀消息,這個是怎么設(shè)計的呢?
我:MessageState 表記錄了用戶的未讀消息數(shù),想要獲取用戶的消息未讀數(shù)時,只需要客戶端調(diào)用一下接口查詢即可獲取,這個接口將每個群的未讀個數(shù)加起來,統(tǒng)一返回給客戶端,然后借助手機(jī)的 SDK 推送功能加載到用戶手機(jī)上。
面試官:就這么簡單嗎,可以優(yōu)化一下不?
我:(內(nèi)心 OS,性能確實很差,就等著你問呢)是的,我們需要優(yōu)化一下,首先 MySQL 查詢 select count 類型的語句時,都會觸發(fā)全表掃描,所以每次加載消息未讀數(shù)都很慢。
為了查詢性能考慮,我們可以將用戶的消息數(shù)量存入 Redis,并實時記錄一個未讀數(shù)值。并且,當(dāng)未讀數(shù)大于 99 時,就將未讀數(shù)值置為 100 且不再增加。
當(dāng)推送用戶消息時,只要未讀數(shù)為 100,就將推送消息數(shù)設(shè)置為 99+,以此來提升存儲的性能和交互的效率。
面試官:嗯,目前幾乎所有的消息推送功能都是這么設(shè)計的。那你再說一下 10 億用戶的群聊系統(tǒng)應(yīng)該如何在高并發(fā),海量數(shù)據(jù)下保證高性能和高可用吧!
我:我想到了幾個點,比如采用集群部署、消息隊列、多線程、緩存等。
集群部署:可擴(kuò)展
在群聊系統(tǒng)中,我們用到了分布式可擴(kuò)展的思想,無論是長連接服務(wù)、消息推送服務(wù),還是數(shù)據(jù)庫以及分布式文件存儲服務(wù),都是集群部署。
一方面防止單體故障,另一方面可以根據(jù)業(yè)務(wù)來進(jìn)行彈性伸縮,提升了系統(tǒng)的高可用性。
消息隊列:異步、削峰
在消息推送時,由于消息量和用戶量很多,所以我們將消息放到消息隊列(比如 Kafka)中異步進(jìn)行消費和推送,來進(jìn)行流量削峰,防止數(shù)據(jù)太多將服務(wù)打崩。
多線程
在消息寫入和消費時,可以多線程操作,一方面節(jié)省了硬件開銷,不至于部署太多機(jī)器。另一方面提升了效率,畢竟多個流水線工作肯定比單打獨斗更快。
其它優(yōu)化
緩存前面已經(jīng)說到了,除了建群時記錄 code,加群時記錄群成員數(shù),我們還可以緩存群聊里最近一段時間的消息,防止每個用戶都去 DB 拉取一遍數(shù)據(jù),這提升了消息查閱的效率。
除此之外,為了節(jié)省成本,可以記錄流量的高峰時間段,根據(jù)時間段來定時擴(kuò)縮節(jié)點(當(dāng)然,這只是為了成本考慮,在實際業(yè)務(wù)中這點開銷不算什么大問題)。
6. 小結(jié)
后續(xù)
面試官:嗯不錯,實際上的架構(gòu)中也沒有節(jié)省這些資源,而是把重心放在了用戶體驗上。(看了看表)OK,那今天的面試就到這,你有什么想問的嗎?
我:(內(nèi)心 OS,有點慌,但是不能表現(xiàn)出來)由于時間有限,之前對系統(tǒng)高并發(fā)、高性能的設(shè)計,以及對海量數(shù)據(jù)的處理淺嘗輒止,這在系統(tǒng)設(shè)計的面試中占比如何?
面試官:整體想得比較全,但是還不夠細(xì)節(jié)。當(dāng)然,也可能是時間不充分的原因,已經(jīng)還不錯了!
我:(內(nèi)心 OS,借你吉言)再想問一下,如果我把這些寫出來,會有讀者給我點贊、分享、加入在看嗎?
面試官:……
結(jié)語
群聊系統(tǒng)是社交應(yīng)用的核心功能之一,每個社交產(chǎn)品幾乎都有著群聊系統(tǒng)的身影:包括但不限于 QQ、微信、抖音、小紅書等。
上述介紹的技術(shù)細(xì)節(jié)可能只是群聊系統(tǒng)的冰山一角,像常見的搶紅包、群內(nèi)音視頻通話這些核心功能也充斥著大量的技術(shù)難點。
但正是有了這些功能,才讓我們使用的 App 變得更加有趣。而這,可能也是技術(shù)和架構(gòu)的魅力所在吧~
標(biāo)題名稱:聽說你會架構(gòu)設(shè)計?來,弄一個群聊系統(tǒng)
文章鏈接:http://fisionsoft.com.cn/article/djhcoog.html


咨詢
建站咨詢
