摘要：來(lái)自作者沈劍更多技術(shù)分享，盡在微信公眾號(hào)技術(shù)雜談前言本文將以好友中心為例，介紹多對(duì)多類業(yè)務(wù)，隨著數(shù)據(jù)量的逐步增大，數(shù)據(jù)庫(kù)性能顯著降低，數(shù)據(jù)庫(kù)水平切分相關(guān)的架構(gòu)實(shí)踐。

來(lái)自 GitChat 作者：沈劍
更多IT技術(shù)分享，盡在微信公眾號(hào)：GitChat技術(shù)雜談

本文將以“好友中心”為例，介紹“多對(duì)多”類業(yè)務(wù)，隨著數(shù)據(jù)量的逐步增大，數(shù)據(jù)庫(kù)性能顯著降低，數(shù)據(jù)庫(kù)水平切分相關(guān)的架構(gòu)實(shí)踐。

所謂的“多對(duì)多”，來(lái)自數(shù)據(jù)庫(kù)設(shè)計(jì)中的“實(shí)體-關(guān)系”ER模型，用來(lái)描述實(shí)體之間的關(guān)聯(lián)關(guān)系，一個(gè)學(xué)生可以選修多個(gè)課程，一個(gè)課程可以被多個(gè)學(xué)生選修，這里學(xué)生與課程時(shí)間的關(guān)系，就是多對(duì)多關(guān)系。

好友關(guān)系主要分為兩類，弱好友關(guān)系與強(qiáng)好友關(guān)系，兩類都有典型的互聯(lián)網(wǎng)產(chǎn)品應(yīng)用。

弱好友關(guān)系的建立，不需要雙方彼此同意：

用戶A關(guān)注用戶B，不需要用戶B同意，此時(shí)用戶A與用戶B為弱好友關(guān)系，對(duì)A而言，暫且理解為“關(guān)注”；

用戶B關(guān)注用戶A，也不需要用戶A同意，此時(shí)用戶A與用戶B也為弱好友關(guān)系，對(duì)A而言，暫且理解為“粉絲”；

微博粉絲是一個(gè)典型的弱好友關(guān)系應(yīng)用。

強(qiáng)好友關(guān)系的建立，需要好友關(guān)系雙方彼此同意：

用戶A請(qǐng)求添加用戶B為好友，用戶B同意，此時(shí)用戶A與用戶B則互為強(qiáng)好友關(guān)系，即A是B的好友，B也是A的好友。

QQ好友是一個(gè)典型的強(qiáng)好友關(guān)系應(yīng)用。

好友中心是一個(gè)典型的多對(duì)多業(yè)務(wù)，一個(gè)用戶可以添加多個(gè)好友，也可以被多個(gè)好友添加，其典型架構(gòu)為：

friend-service：好友中心服務(wù)，對(duì)調(diào)用者提供友好的RPC接口

db：對(duì)好友數(shù)據(jù)進(jìn)行存儲(chǔ)

通過(guò)弱好友關(guān)系業(yè)務(wù)分析，很容易了解到，其核心元數(shù)據(jù)為：

guanzhu(uid, guanzhu_uid);

fensi(uid, fensi_uid);

其中：

guanzhu表，用戶記錄uid所有關(guān)注用戶guanzhu_uid

fensi表，用來(lái)記錄uid所有粉絲用戶fensi_uid

需要強(qiáng)調(diào)的是，一條弱關(guān)系的產(chǎn)生，會(huì)產(chǎn)生兩條記錄，一條關(guān)注記錄，一條粉絲記錄。

例如：用戶A(uid=1)關(guān)注了用戶B(uid=2)，A多關(guān)注了一個(gè)用戶，B多了一個(gè)粉絲，于是：

guanzhu表要插入{1, 2}這一條記錄，1關(guān)注了2

fensi表要插入{2, 1}這一條記錄，2粉了1

如何查詢一個(gè)用戶關(guān)注了誰(shuí)呢？
回答：在guanzhu的uid上建立索引：
select * from guanzhu where uid=1;
即可得到結(jié)果，1關(guān)注了2。
如何查詢一個(gè)用戶粉了誰(shuí)呢？
回答：在fensi的uid上建立索引：
select * from fensi where uid=2;
即可得到結(jié)果，2粉了1。

通過(guò)強(qiáng)好友關(guān)系業(yè)務(wù)分析，很容易了解到，其核心元數(shù)據(jù)為：

friend(uid1, uid2);

其中：

uid1，強(qiáng)好友關(guān)系中一方的uid

uid2，強(qiáng)好友關(guān)系中另一方的uid

uid=1的用戶添加了uid=2的用戶，雙方都同意加彼此為好友，這個(gè)強(qiáng)好友關(guān)系，在數(shù)據(jù)庫(kù)中應(yīng)該插入記錄{1, 2}還是記錄{2,1 }呢？

回答：都可以，為了避免歧義，可以人為約定，插入記錄時(shí)uid1的值必須小于uid2。

例如：有uid=1,2,3三個(gè)用戶，他們互為強(qiáng)好友關(guān)系，那邊數(shù)據(jù)庫(kù)中可能是這樣的三條記錄

{1, 2}

{2, 3}

{1,3 }

如何查詢一個(gè)用戶的好友呢？
回答：假設(shè)要查詢uid=2的所有好友，只需在uid1和uid2上建立索引，然后：
select * from friend where uid1=2
union
select * from friend where uid2=2
即可得到結(jié)果。

作業(yè)：為何不使用這樣的SQL語(yǔ)句呢？

select * from friend uid1=2 or uid2=2

供大家思考。

強(qiáng)好友關(guān)系是弱好友關(guān)系的一個(gè)特例，A和B必須互為關(guān)注關(guān)系（也可以說(shuō)，同時(shí)互為粉絲關(guān)系），即也可以使用關(guān)注表和粉絲表來(lái)實(shí)現(xiàn)：

guanzhu(uid, guanzhu_uid);

fensi(uid, fensi_uid);

例如：用戶A(uid=1)和用戶B(uid=2)為強(qiáng)好友關(guān)系，即相互關(guān)注：
用戶A(uid=1)關(guān)注了用戶B(uid=2)，A多關(guān)注了一個(gè)用戶，B多了一個(gè)粉絲，于是：

guanzhu表要插入{1, 2}這一條記錄

fensi表要插入{2, 1}這一條記錄

同時(shí)，用戶B(uid=2)也關(guān)注了用戶A(uid=1)，B多關(guān)注了一個(gè)用戶，A多了一個(gè)粉絲，于是：

guanzhu表要插入{2, 1}這一條記錄

fensi表要插入{1, 2}這一條記錄

對(duì)于強(qiáng)好友關(guān)系的兩類實(shí)現(xiàn)：

friend(uid1, uid2)表

數(shù)據(jù)冗余guanzhu表與fensi表（后文稱正表T1與反表T2）

在數(shù)據(jù)量小時(shí)，看似無(wú)差異，但數(shù)據(jù)量大時(shí)，數(shù)據(jù)冗余的優(yōu)勢(shì)就體現(xiàn)出來(lái)了：

friend表，數(shù)據(jù)量大時(shí)，如果使用uid1來(lái)分庫(kù)，那么uid2上的查詢就需要遍歷多庫(kù)

正表T1與反表T2通過(guò)數(shù)據(jù)冗余來(lái)實(shí)現(xiàn)好友關(guān)系，{1,2}{2,1}分別存在于兩表中，故兩個(gè)表都使用uid來(lái)分庫(kù)，均只需要進(jìn)行一次查詢，就能找到對(duì)應(yīng)的關(guān)注與粉絲，而不需要多個(gè)庫(kù)掃描

數(shù)據(jù)冗余，是多對(duì)多關(guān)系，在數(shù)據(jù)量大時(shí)，數(shù)據(jù)水平切分的常用實(shí)踐。

接下來(lái)的問(wèn)題轉(zhuǎn)化為，好友中心服務(wù)如何來(lái)進(jìn)行數(shù)據(jù)冗余，常見(jiàn)有三種方法。

顧名思義，由好友中心服務(wù)同步寫(xiě)冗余數(shù)據(jù)，如上圖1-4流程：

業(yè)務(wù)方調(diào)用服務(wù)，新增數(shù)據(jù)

服務(wù)先插入T1數(shù)據(jù)

服務(wù)再插入T2數(shù)據(jù)

服務(wù)返回業(yè)務(wù)方新增數(shù)據(jù)成功

優(yōu)點(diǎn)：

不復(fù)雜，服務(wù)層由單次寫(xiě)，變兩次寫(xiě)

數(shù)據(jù)一致性相對(duì)較高（因?yàn)殡p寫(xiě)成功才返回）

缺點(diǎn)：

請(qǐng)求的處理時(shí)間增加（要插入次，時(shí)間加倍）

數(shù)據(jù)仍可能不一致，例如第二步寫(xiě)入T1完成后服務(wù)重啟，則數(shù)據(jù)不會(huì)寫(xiě)入T2

如果系統(tǒng)對(duì)處理時(shí)間比較敏感，引出常用的第二種方案

數(shù)據(jù)的雙寫(xiě)并不再由好友中心服務(wù)來(lái)完成，服務(wù)層異步發(fā)出一個(gè)消息，通過(guò)消息總線發(fā)送給一個(gè)專門(mén)的數(shù)據(jù)復(fù)制服務(wù)來(lái)寫(xiě)入冗余數(shù)據(jù)，如上圖1-6流程：

業(yè)務(wù)方調(diào)用服務(wù)，新增數(shù)據(jù)

服務(wù)先插入T1數(shù)據(jù)

服務(wù)向消息總線發(fā)送一個(gè)異步消息（發(fā)出即可，不用等返回，通常很快就能完成）

服務(wù)返回業(yè)務(wù)方新增數(shù)據(jù)成功

消息總線將消息投遞給數(shù)據(jù)同步中心

數(shù)據(jù)同步中心插入T2數(shù)據(jù)

優(yōu)點(diǎn)：

請(qǐng)求處理時(shí)間短（只插入1次）

缺點(diǎn)：

系統(tǒng)的復(fù)雜性增加了，多引入了一個(gè)組件（消息總線）和一個(gè)服務(wù)（專用的數(shù)據(jù)復(fù)制服務(wù)）

因?yàn)榉祷貥I(yè)務(wù)線數(shù)據(jù)插入成功時(shí)，數(shù)據(jù)還不一定插入到T2中，因此數(shù)據(jù)有一個(gè)不一致時(shí)間窗口（這個(gè)窗口很短，最終是一致的）

在消息總線丟失消息時(shí)，冗余表數(shù)據(jù)會(huì)不一致

如果想解除“數(shù)據(jù)冗余”對(duì)系統(tǒng)的耦合，引出常用的第三種方案

數(shù)據(jù)的雙寫(xiě)不再由好友中心服務(wù)來(lái)完成，而是由線下的一個(gè)服務(wù)或者任務(wù)來(lái)完成，如上圖1-6流程：

業(yè)務(wù)方調(diào)用服務(wù)，新增數(shù)據(jù)

服務(wù)先插入T1數(shù)據(jù)

服務(wù)返回業(yè)務(wù)方新增數(shù)據(jù)成功

數(shù)據(jù)會(huì)被寫(xiě)入到數(shù)據(jù)庫(kù)的log中

線下服務(wù)或者任務(wù)讀取數(shù)據(jù)庫(kù)的log

線下服務(wù)或者任務(wù)插入T2數(shù)據(jù)

優(yōu)點(diǎn)：

數(shù)據(jù)雙寫(xiě)與業(yè)務(wù)完全解耦

請(qǐng)求處理時(shí)間短（只插入1次）

缺點(diǎn)：

返回業(yè)務(wù)線數(shù)據(jù)插入成功時(shí)，數(shù)據(jù)還不一定插入到T2中，因此數(shù)據(jù)有一個(gè)不一致時(shí)間窗口（這個(gè)窗口很短，最終是一致的）

數(shù)據(jù)的一致性依賴于線下服務(wù)或者任務(wù)的可靠性

上述三種方案各有優(yōu)缺點(diǎn)，可以結(jié)合實(shí)際情況選取。

數(shù)據(jù)冗余固然能夠解決多對(duì)多關(guān)系的數(shù)據(jù)庫(kù)水平切分問(wèn)題，但又帶來(lái)了新的問(wèn)題，如何保證正表T1與反表T2的數(shù)據(jù)一致性呢？

上一節(jié)的討論可以看到，不管哪種方案，因?yàn)閮刹讲僮鞑荒鼙ＷC原子性，總有出現(xiàn)數(shù)據(jù)不一致的可能，高吞吐分布式事務(wù)是業(yè)內(nèi)尚未解決的難題，此時(shí)的架構(gòu)優(yōu)化方向，并不是完全保證數(shù)據(jù)的一致，而是盡早的發(fā)現(xiàn)不一致，并修復(fù)不一致。

最終一致性，是高吞吐互聯(lián)網(wǎng)業(yè)務(wù)一致性的常用實(shí)踐。更具體的，保證數(shù)據(jù)最終一致性的方案有三種。

如上圖所示，線下啟動(dòng)一個(gè)離線的掃描工具，不停的比對(duì)正表T1和反表T2，如果發(fā)現(xiàn)數(shù)據(jù)不一致，就進(jìn)行補(bǔ)償修復(fù)。

優(yōu)點(diǎn)：

比較簡(jiǎn)單，開(kāi)發(fā)代價(jià)小

線上服務(wù)無(wú)需修改，修復(fù)工具與線上服務(wù)解耦

缺點(diǎn)：

掃描效率低，會(huì)掃描大量的“已經(jīng)能夠保證一致”的數(shù)據(jù)

由于掃描的數(shù)據(jù)量大，掃描一輪的時(shí)間比較長(zhǎng)，即數(shù)據(jù)如果不一致，不一致的時(shí)間窗口比較長(zhǎng)

有沒(méi)有只掃描“可能存在不一致可能性”的數(shù)據(jù)，而不是每次掃描全部數(shù)據(jù)，以提高效率的優(yōu)化方法呢？

每次只掃描增量的日志數(shù)據(jù)，就能夠極大提高效率，縮短數(shù)據(jù)不一致的時(shí)間窗口，如上圖1-4流程所示：

寫(xiě)入正表T1

第一步成功后，寫(xiě)入日志log1

寫(xiě)入反表T2

第二步成功后，寫(xiě)入日志log2

當(dāng)然，我們還是需要一個(gè)離線的掃描工具，不停的比對(duì)日志log1和日志log2，如果發(fā)現(xiàn)數(shù)據(jù)不一致，就進(jìn)行補(bǔ)償修復(fù)

優(yōu)點(diǎn)：

雖比方法一復(fù)雜，但仍然是比較簡(jiǎn)單的

數(shù)據(jù)掃描效率高，只掃描增量數(shù)據(jù)

缺點(diǎn)：

線上服務(wù)略有修改（代價(jià)不高，多寫(xiě)了2條日志）

雖然比方法一更實(shí)時(shí)，但時(shí)效性還是不高，不一致窗口取決于掃描的周期

有沒(méi)有實(shí)時(shí)檢測(cè)一致性并進(jìn)行修復(fù)的方法呢？

這次不是寫(xiě)日志了，而是向消息總線發(fā)送消息，如上圖1-4流程所示：

寫(xiě)入正表T1

第一步成功后，發(fā)送消息msg1

寫(xiě)入反表T2

第二步成功后，發(fā)送消息msg2

這次不是需要一個(gè)周期掃描的離線工具了，而是一個(gè)實(shí)時(shí)訂閱消息的服務(wù)不停的收消息。

假設(shè)正常情況下，msg1和msg2的接收時(shí)間應(yīng)該在3s以內(nèi)，如果檢測(cè)服務(wù)在收到msg1后沒(méi)有收到msg2，就嘗試檢測(cè)數(shù)據(jù)的一致性，不一致時(shí)進(jìn)行補(bǔ)償修復(fù)

優(yōu)點(diǎn)：

效率高

實(shí)時(shí)性高

缺點(diǎn)：

方案比較復(fù)雜，上線引入了消息總線這個(gè)組件

線下多了一個(gè)訂閱總線的檢測(cè)服務(wù)

however，技術(shù)方案本身就是一個(gè)投入產(chǎn)出比的折衷，可以根據(jù)業(yè)務(wù)對(duì)一致性的需求程度決定使用哪一種方法。

文字較多，希望盡量記住如下幾點(diǎn)：

好友業(yè)務(wù)是一個(gè)典型的多對(duì)多關(guān)系，又分為強(qiáng)好友與弱好友 。

數(shù)據(jù)冗余是一個(gè)常見(jiàn)的多對(duì)多業(yè)務(wù)數(shù)據(jù)水平切分實(shí)踐。

冗余數(shù)據(jù)的常見(jiàn)方案有三種：

服務(wù)同步冗余

服務(wù)異步冗余

線下異步冗余

數(shù)據(jù)冗余會(huì)帶來(lái)一致性問(wèn)題，高吞吐互聯(lián)網(wǎng)業(yè)務(wù)，要想完全保證事務(wù)一致性很難，常見(jiàn)的實(shí)踐是最終一致性。

最終一致性的常見(jiàn)實(shí)踐是，盡快找到不一致，并修復(fù)數(shù)據(jù)，常見(jiàn)方案有三種。

線下全量掃描法

線下增量掃描法

線上實(shí)時(shí)檢測(cè)法

以訂單中心為典型的“多KEY”類業(yè)務(wù)的水平拆分架構(gòu)又應(yīng)該怎么處理，敬請(qǐng)期待下期。

我們 GitChat 經(jīng)過(guò)半年的運(yùn)營(yíng)，在產(chǎn)品形態(tài)上不斷改進(jìn)。

這次，我們將系統(tǒng)性的優(yōu)化 GitChat 一些內(nèi)容，在原有 Chat 基礎(chǔ)上推出新的內(nèi)容分享產(chǎn)品：

GitQ 精品課程

如果您在 IT技術(shù)上有自己獨(dú)到的學(xué)習(xí)心得 或 自成體系的技術(shù)成長(zhǎng)套路，我們非常期待您能在 GitQ 上進(jìn)一步實(shí)現(xiàn)：

GitQ 定位：具備專業(yè)性、成體系的IT類課程

GitQ 形態(tài)：獨(dú)家文章（6~12篇）+讀者圈答疑

GitQ 定價(jià)：9.99 / 19.99 等

【作者如何開(kāi)設(shè) GitQ 精品課？】

提交如下內(nèi)容：課程名稱 / 用戶定位 / 課程大綱

GitChat 進(jìn)行內(nèi)容評(píng)估與課程策劃

雙方確定課程細(xì)節(jié)、交付時(shí)間

GitChat 完成課程的上線、宣傳推廣

【作者注意事項(xiàng)】

GitQ 精品課內(nèi)的文章，在課程上線一年內(nèi)屬于 GitChat 獨(dú)家使用。

按約定時(shí)間準(zhǔn)時(shí)交付文章。

課程上線后，積極在讀者圈回答用戶的提問(wèn)。

【更多咨詢】
在微信公眾號(hào): GitChat技術(shù)雜談（GitChat_Club） 留言 ，或加微信聯(lián)系 GitChat 主編：ztx415

實(shí)錄：《沈劍：“多對(duì)多”類業(yè)務(wù)數(shù)據(jù)庫(kù)水平切分架構(gòu)解析》