本文由網(wǎng)易云信李興分享，原題“深度剖析“圈組”深度剖析“圈組”關(guān)系系統(tǒng)設(shè)計(jì)”，為了提升內(nèi)容品質(zhì)，本文收錄時(shí)有修訂。

1、引言

上篇《百萬級(jí)成員實(shí)時(shí)社群技術(shù)實(shí)現(xiàn)（消息系統(tǒng)篇）》中，我們分享了云信“圈組”（“圈組”是云信的類Discord產(chǎn)品實(shí)現(xiàn)方案）消息系統(tǒng)的技術(shù)設(shè)計(jì)和實(shí)踐。

本篇接上篇，將繼續(xù)分享云信“圈組”的關(guān)系系統(tǒng)在技術(shù)架構(gòu)上的設(shè)計(jì)和實(shí)現(xiàn)。希望帶給你啟發(fā)。

?

技術(shù)交流：

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4333-1-1.html）

2、系列文章

本文是系列文章中的第?3?篇：

• 《實(shí)時(shí)社群技術(shù)專題(一)：支持百萬人超級(jí)群聊，一文讀懂社群產(chǎn)品Discord》

• 《實(shí)時(shí)社群技術(shù)專題(二)：百萬級(jí)成員實(shí)時(shí)社群技術(shù)實(shí)現(xiàn)（消息系統(tǒng)篇）》

• 《實(shí)時(shí)社群技術(shù)專題(三)：百萬級(jí)成員實(shí)時(shí)社群技術(shù)實(shí)現(xiàn)（關(guān)系系統(tǒng)篇）》（* 本文）

3、作者介紹

李興：網(wǎng)易云信資深服務(wù)端開發(fā)工程師，畢業(yè)于浙江大學(xué)，碩士畢業(yè)后加入網(wǎng)易，負(fù)責(zé)云信 IM等業(yè)務(wù)的服務(wù)器開發(fā)。專注于即時(shí)通訊以及相關(guān)中間件等技術(shù)。

4、“圈組”的關(guān)系業(yè)務(wù)特點(diǎn)

4.1概述

在互聯(lián)網(wǎng)行業(yè)盛行一句話，技術(shù)是為業(yè)務(wù)服務(wù)的。具體到技術(shù)實(shí)踐中，一個(gè)重要方面就是要面向業(yè)務(wù)特點(diǎn)設(shè)計(jì)技術(shù)方案。

因此，想要了解“圈組”的關(guān)系系統(tǒng)設(shè)計(jì)，就要首先了解“圈組”的關(guān)系業(yè)務(wù)特點(diǎn)。

4.2業(yè)務(wù)特點(diǎn)

“圈組”的關(guān)系業(yè)務(wù)特點(diǎn)是什么？

• 1）其一：是關(guān)系復(fù)雜，即關(guān)系主體多、管理機(jī)制雜、聯(lián)動(dòng)耦合重；

• 2）其二：是規(guī)模巨大，即成員數(shù)量可達(dá)百萬量級(jí)、變更批量可達(dá)百萬量級(jí)。

所謂關(guān)系復(fù)雜，具體來講：首先是關(guān)系主體多。

在“圈組”業(yè)務(wù)中，關(guān)系主體包括：

• 1）服務(wù)器：承載社群關(guān)系，負(fù)責(zé)社群成員關(guān)系維護(hù)；

• 2）頻道：從屬于服務(wù)器，承載內(nèi)容關(guān)系，負(fù)責(zé)內(nèi)容互動(dòng)關(guān)系維護(hù)；

• 3）身份組：可從屬于服務(wù)器或頻道，承載身份權(quán)限關(guān)系，負(fù)責(zé)身份設(shè)定和權(quán)限配置；

• 4）頻道分組：從屬于服務(wù)器，又關(guān)聯(lián)一組頻道，承載頻道模版關(guān)系，負(fù)責(zé)分類頻道和共享配置。

其次是：管理機(jī)制雜。

在“圈組”業(yè)務(wù)中，僅就成員管理機(jī)制而言：

• 1）服務(wù)器成員采用邀請(qǐng)/申請(qǐng)機(jī)制；

• 2）頻道成員采用公開/私密模式+黑/白名單機(jī)制；

• 3）身份組成員采用加入/移出機(jī)制；

• 4）頻道分組成員與頻道成員采用同步機(jī)制。

最后是：聯(lián)動(dòng)耦合。

在“圈組”業(yè)務(wù)中，以頻道成員維護(hù)為例：頻道成員不僅受到公開/私密模式+黑/白名單配置變更的影響，而且會(huì)伴隨服務(wù)器成員變更、身份組變更、身份組成員變更等做聯(lián)動(dòng)變更。

所謂規(guī)模巨大，具體來講：

• 1）一方面：成員數(shù)量可達(dá)百萬量級(jí)（在“圈組”業(yè)務(wù)中，服務(wù)器成員數(shù)量可以達(dá)到數(shù)百萬人）；

• 2）進(jìn)一步：百萬成員服務(wù)器下的頻道和身份組，其成員數(shù)量也可以達(dá)到百萬量級(jí)；

• 3）另一面：是變更批量可達(dá)百萬量級(jí)。

所謂變更批量可達(dá)百萬量級(jí)，包括：刪除百萬成員的服務(wù)器/頻道/身份組，增刪頻道/頻道分組黑白名單中的百萬成員身份組等。

從“圈組”關(guān)系業(yè)務(wù)的兩大特點(diǎn)出發(fā)，可以發(fā)現(xiàn)：“圈組”關(guān)系是不同于群組關(guān)系的全新業(yè)務(wù)場(chǎng)景，將會(huì)面臨全新的技術(shù)難點(diǎn)。

5、“圈組”關(guān)系系統(tǒng)的技術(shù)難點(diǎn)

5.1概述

技術(shù)難點(diǎn)主要有兩個(gè)方面：

• 1）其一：是多關(guān)系主體、多管理機(jī)制在層級(jí)結(jié)構(gòu)下關(guān)聯(lián)耦合導(dǎo)致的業(yè)務(wù)邏輯的復(fù)雜性；

• 2）其二：是成員數(shù)量、變更批量規(guī)模巨大導(dǎo)致的業(yè)務(wù)處理在時(shí)間、空間、資源等開銷上的復(fù)雜性。

5.2業(yè)務(wù)邏輯復(fù)雜性

1）首先“圈組”有多級(jí)結(jié)構(gòu)：

包括服務(wù)器/頻道二級(jí)結(jié)構(gòu)、服務(wù)器/頻道分組/頻道三級(jí)結(jié)構(gòu)等。

單個(gè)關(guān)系主體變更，不僅涉及自身的變更，而且涉及上下級(jí)關(guān)系主體的變更，可以說牽一發(fā)動(dòng)全身。相比而言，群組是沒有層級(jí)的，群組變更只要獨(dú)善其身就好。

2）其次“圈組”有身份組：

一個(gè)身份組是一組有共同權(quán)限的服務(wù)器成員的集合，不同身份組的成員可以相互交叉，身份組會(huì)作為整體參與到成員管理中。

也就是說，成員變更不再只是個(gè)別成員（1-100人）的進(jìn)入退出，將會(huì)出現(xiàn)整組成員（1-1000000人）的大進(jìn)大出。相比而言，群組是沒有身份組的，群組特殊成員包括群主、管理員等也都數(shù)量不多、互不重復(fù)。

3）最后“圈組”有多種成員管理機(jī)制：

服務(wù)器成員和身份組成員的管理機(jī)制與群組類似，頻道成員和頻道分組成員的管理機(jī)制卻是全新模式。

頻道分為公開和私密兩種：

• 1）公開模式默認(rèn)允許所有服務(wù)器成員可見，但要排除黑名單身份組和黑名單成員；

• 2）私密模式默認(rèn)不許所有服務(wù)器成員可見，但要放開白名單身份組和白名單成員。

除了受到公開/私密模式+黑/白名單配置變更的影響，頻道成員也受到所依賴的關(guān)系主體（服務(wù)器成員、身份組、身份組成員）變更的影響。進(jìn)一步，頻道成員還受到所同步的頻道分組變更的影響。相比而言，群組成員的邀請(qǐng)/申請(qǐng)機(jī)制，可以說是小巫見大巫。

5.3業(yè)務(wù)處理復(fù)雜性

1）首先是成員數(shù)量規(guī)模巨大：

由于成員數(shù)量可達(dá)百萬，整個(gè)成員列表的存儲(chǔ)空間開銷、網(wǎng)絡(luò)傳輸開銷，變得十分巨大，不論全量成員列表數(shù)據(jù)的服務(wù)器緩存，還是全量成員列表數(shù)據(jù)從服務(wù)器到客戶端的同步，都將變得難以實(shí)現(xiàn)。

2）其次是變更批量規(guī)模巨大：

單次接口調(diào)用的關(guān)系變更，可能伴隨百萬規(guī)模的聯(lián)動(dòng)關(guān)系變更，這會(huì)導(dǎo)致巨大的處理時(shí)間開銷、計(jì)算資源開銷，不論所有變更同步完成處理，還是所有變更單機(jī)完成處理，都將變得難以實(shí)現(xiàn)。

3）最后是通知消息規(guī)模巨大：

關(guān)系系統(tǒng)不僅需要做關(guān)系變更的數(shù)據(jù)處理，而且需要通知變更結(jié)果到客戶端。由于在“圈組”中各個(gè)關(guān)系主體的成員數(shù)量規(guī)模巨大，使得單個(gè)變更需要擴(kuò)散為百萬通知同時(shí)下發(fā)，所需計(jì)算資源開銷、網(wǎng)絡(luò)傳輸開銷十分巨大。

相比而言，群組方案因?yàn)槌蓡T數(shù)量、變更批量規(guī)模有限，并不涉及這些技術(shù)難點(diǎn)。

從“圈組”關(guān)系系統(tǒng)的兩個(gè)方面技術(shù)難點(diǎn)出發(fā)，可以發(fā)現(xiàn)：“圈組”關(guān)系系統(tǒng)面臨不同于群組的全新技術(shù)難點(diǎn)，想要解決這些技術(shù)難點(diǎn)，需要?jiǎng)?chuàng)新的技術(shù)方案。

6、“圈組”的整體架構(gòu)

“圈組”方案的整體架構(gòu)：

上面展示了“圈組”方案的整體架構(gòu)，可以看到“圈組”整體是一個(gè)分層架構(gòu)。

從上到下看：

1）客戶層：包括可供客戶端集成的移動(dòng)端、桌面端、跨平臺(tái) SDK，和可供服務(wù)器調(diào)用的 OpenAPI；

2）接入層：包括 LBS 服務(wù)、長(zhǎng)連接服務(wù)和 API 網(wǎng)關(guān)，分別對(duì)應(yīng)客戶端 SDK 和用戶服務(wù)器；

3）網(wǎng)絡(luò)層：包括自研的全球?qū)崟r(shí)傳輸網(wǎng)絡(luò) WE-CAN；

4）業(yè)務(wù)層：包括用于 SDK 業(yè)務(wù)處理的 App 服務(wù)和用于 OpenAPI 業(yè)務(wù)處理的 WebServer 服務(wù)；

5）服務(wù)層：劃分有登錄、消息、關(guān)系、身份組、支持等服務(wù)模塊，每個(gè)服務(wù)模塊包括有多個(gè)微服務(wù)或消費(fèi)者；

6）基礎(chǔ)設(shè)施層：包括系統(tǒng)所用的數(shù)據(jù)庫(kù)和中間件。

7、“圈組”關(guān)系系統(tǒng)的架構(gòu)

上圖展示了“圈組”關(guān)系系統(tǒng)的技術(shù)架構(gòu)?？梢钥吹健叭M”關(guān)系系統(tǒng)遍及“圈組”架構(gòu)的接入層、網(wǎng)絡(luò)層、業(yè)務(wù)層和服務(wù)層。

從功能出發(fā)整體上分為三個(gè)部分：

• 1）關(guān)系操作同步處理模塊；

• 2）關(guān)系事件異步處理模塊；

• 3）變更通知在線廣播模塊。

下面具體討論三個(gè)方案要點(diǎn)的技術(shù)細(xì)節(jié)，包括頻道成員關(guān)系管理、變更通知在線廣播和關(guān)系數(shù)據(jù)云端檢索。

8、關(guān)系系統(tǒng)技術(shù)實(shí)現(xiàn)1：頻道成員關(guān)系管理

頻道成員關(guān)系管理，是“圈組”中極具挑戰(zhàn)性的問題。

頻道成員涉及多關(guān)系主體、多管理機(jī)制、聯(lián)動(dòng)變更耦合嚴(yán)重，成員數(shù)量和變更批量規(guī)模巨大，可以說是“圈組”關(guān)系業(yè)務(wù)的典型代表。

頻道成員關(guān)系管理在業(yè)務(wù)邏輯和業(yè)務(wù)處理兩方面的復(fù)雜性可想而知。

針對(duì)頻道成員關(guān)系管理問題，“圈組”設(shè)計(jì)了兩大機(jī)制加以解決。

包括：

• 1）終態(tài)維護(hù)與過渡計(jì)算相結(jié)合機(jī)制；

• 2）事件按序異步并行處理機(jī)制。

終態(tài)維護(hù)與過渡計(jì)算相結(jié)合機(jī)制，具體來講：頻道成員關(guān)系數(shù)據(jù)最終被維護(hù)在持久化數(shù)據(jù)庫(kù)中，并在頻道成員沒有變更的終態(tài)階段，直接支持頻道成員數(shù)據(jù)的查詢需求。當(dāng)頻道成員發(fā)生變更時(shí)，由于變更邏輯和變更處理兩方面的復(fù)雜性，完成關(guān)系變更需要一段時(shí)間，稱之為過渡階段。

在過渡階段，數(shù)據(jù)庫(kù)持久化的頻道成員表數(shù)據(jù)是不完全準(zhǔn)確的，無法直接支持頻道成員數(shù)據(jù)的查詢需求。此時(shí)轉(zhuǎn)為由頻道成員配置元數(shù)據(jù)直接計(jì)算頻道成員以支持查詢需求。因?yàn)轭l道成員配置元數(shù)據(jù)的變更是同步處理的，所以在過渡階段由頻道成員配置元數(shù)據(jù)直接計(jì)算頻道成員可以保證查詢準(zhǔn)確性。通過將頻道成員關(guān)系管理分為終態(tài)和過渡兩個(gè)階段，并在不同階段采用不同頻道成員查詢方案，不僅解決了單純由計(jì)算獲取頻道成員資源開銷大的問題，而且解決了頻道成員變更延遲導(dǎo)致由數(shù)據(jù)庫(kù)獲取頻道成員結(jié)果不準(zhǔn)確的問題。

除了頻道成員的獲取查詢問題，頻道成員的變更處理也很重要。

事件按序異步并行處理機(jī)制，就是用于解決頻道成員的變更處理問題：

• 1）其一：通過將影響頻道成員關(guān)系的變更操作分層級(jí)、系統(tǒng)化定義為變更事件，顯著降低頻道成員關(guān)系管理的業(yè)務(wù)邏輯復(fù)雜性；

• 2）其二：通過 ID 哈希、分布式鎖、事件版本號(hào)控制等保證變更事件的按序處理，有效避免事件處理亂序?qū)е碌某志没瘮?shù)據(jù)錯(cuò)誤；

• 3）其三：通過消息隊(duì)列中轉(zhuǎn)事件并在消費(fèi)者上異步處理，有效解決聯(lián)動(dòng)變更批量過大導(dǎo)致接口調(diào)用阻塞的問題；

• 4）其四：通過在單個(gè)事件處理中的多線程并行加速和本地緩存重用加速，顯著縮短頻道成員關(guān)系變更的時(shí)間延遲。

9、關(guān)系系統(tǒng)技術(shù)實(shí)現(xiàn)2：變更通知在線廣播

關(guān)系系統(tǒng)不僅需要做關(guān)系變更的數(shù)據(jù)處理，而且需要通知變更結(jié)果到客戶端。

在百萬量級(jí)的“圈組”關(guān)系中，每條關(guān)系變更通知，都會(huì)面臨海量擴(kuò)散的接收者。除了通知分發(fā)量激增，不同接收者對(duì)于通知接收的緩急差異也值得關(guān)注。

針對(duì)變更通知在線廣播問題， 我們?cè)O(shè)計(jì)了兩大機(jī)制：

• 1）變更分類通知機(jī)制；

• 2）數(shù)據(jù)通知拉取機(jī)制。

在變更分類通知機(jī)制中：一方面，根據(jù)相關(guān)人員在變更中的角色，劃分為參與者和觀察者分類做通知，即參與者一定通知，觀察者按照訂閱需求通知。其中參與者一般是變更中的少數(shù)關(guān)鍵人員，觀察者則是除了參與者之外可以看到變更結(jié)果的其它人員。通過分類通知，不同接收者對(duì)于通知接收的緩急差異得到合理關(guān)注，變更通知的擴(kuò)散規(guī)模也得到精準(zhǔn)縮小。

另一方面，觀察者按照訂閱需求通知，可以充分發(fā)揮“圈組”的在線廣播訂閱模式的優(yōu)勢(shì)。所謂在線廣播訂閱模式，是指在用戶登陸之后，需要訂閱感興趣的服務(wù)器/頻道的通知，“圈組”系統(tǒng)會(huì)記錄下這些訂閱信息，當(dāng)有新的通知時(shí)，“圈組”系統(tǒng)通過訂閱關(guān)系而非成員列表 + 在線狀態(tài)獲取需要在線廣播的用戶列表，從而不再需要遍歷服務(wù)器/頻道的所有成員及其在線狀態(tài)。通過采用在線廣播訂閱模式，不僅顯著降低變更通知在線廣播的計(jì)算開銷和帶寬開銷，而且可以實(shí)現(xiàn)變更通知在線廣播在長(zhǎng)連接服務(wù)集群的并行加速和水平擴(kuò)展。

變更通知的最終目的是將變更后的數(shù)據(jù)給到客戶端：不同于群組，“圈組”并不將變更后的數(shù)據(jù)直接由通知帶給客戶端，而是采用通知客戶端有變更再觸發(fā)客戶端拉取結(jié)果數(shù)據(jù)的機(jī)制。

究其原因，不同于群組將關(guān)系數(shù)據(jù)全量同步到客戶端，“圈組”客戶端不再存儲(chǔ)關(guān)系數(shù)據(jù)的全量鏡像，因此不再需要通過全量歷史 + 增量變更的方式維護(hù)客戶端上的關(guān)系數(shù)據(jù)全量鏡像。

與此同時(shí)，訂閱變更通知的觀察者也并不是每時(shí)每刻都要關(guān)心變更的結(jié)果數(shù)據(jù)，關(guān)心某次變更結(jié)果數(shù)據(jù)的觀察者相比訂閱變更通知的觀察者在數(shù)量上會(huì)少很多，因此，數(shù)據(jù)通知拉取機(jī)制會(huì)顯著降低變更通知的資源開銷。

另外，相比帶變更數(shù)據(jù)通知，只通知有變更，便于直接合并相同類型的通知，而不用關(guān)心合并變更數(shù)據(jù)存在的時(shí)序、并發(fā)等問題，如此，數(shù)據(jù)通知拉取機(jī)制可以通過短時(shí)間內(nèi)通知合并顯著降低服務(wù)器在線廣播開銷和客戶端通知接收開銷。

10、關(guān)系系統(tǒng)技術(shù)實(shí)現(xiàn)3：關(guān)系數(shù)據(jù)云端檢索

在“圈組”中，伴隨關(guān)系規(guī)模的大幅增長(zhǎng)，群組基于應(yīng)用服務(wù)器全量查詢關(guān)系數(shù)據(jù)或客戶端全量同步關(guān)系數(shù)據(jù)實(shí)現(xiàn)精準(zhǔn)查詢和靈活排序的方案不再適用。

對(duì)此，“圈組”采用了關(guān)系數(shù)據(jù)云端檢索的方案。

“圈組”關(guān)系數(shù)據(jù)云端檢索方案可支持服務(wù)器、頻道、成員等的檢索能力。

從檢索場(chǎng)景上分，包括：

• 1）廣場(chǎng)檢索：用于檢索感興趣的服務(wù)器?？梢愿鶕?jù)名稱、類別等多種維度檢索。檢索結(jié)果可以根據(jù)預(yù)定義字段（成員數(shù)量等）或自定義值（數(shù)據(jù)熱度等）等進(jìn)行排序；

• 2）內(nèi)部檢索：用于檢索用戶可見的服務(wù)器、頻道、成員等。可以根據(jù)名稱、昵稱等多種維度檢索。檢索結(jié)果可以根據(jù)預(yù)定義字段（創(chuàng)建時(shí)間等）或自定義值（數(shù)據(jù)熱度等）等進(jìn)行排序。

11、相關(guān)資料

[1]?一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等

[2]?以微博類應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟

[3]?IM開發(fā)技術(shù)學(xué)習(xí)：揭秘微信朋友圈這種信息推流背后的系統(tǒng)設(shè)計(jì)

[4]?直播系統(tǒng)聊天技術(shù)(四)：百度直播的海量用戶實(shí)時(shí)消息系統(tǒng)架構(gòu)演進(jìn)實(shí)踐

[5]?喜馬拉雅億級(jí)用戶量的離線消息推送系統(tǒng)架構(gòu)設(shè)計(jì)實(shí)踐

[6]?企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)

[7]?企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等

（本文已同步發(fā)布于：http://www.52im.net/thread-4333-1-1.html）