現(xiàn)代IM系統(tǒng)中消息推送和存儲(chǔ)架構(gòu)的實(shí)現(xiàn)

即時(shí)通訊（Instant Messaging，簡(jiǎn)稱IM）是一個(gè)實(shí)時(shí)通信系統(tǒng)，允許兩人或多人使用網(wǎng)絡(luò)實(shí)時(shí)的傳遞文字消息、文件、語音與視頻交流。實(shí)現(xiàn)方式有兩種。第一種基于Server轉(zhuǎn)發(fā)的，Client雙方通信會(huì)經(jīng)過Server轉(zhuǎn)發(fā)來完成消息傳遞。例如QQ、微信。

第二種是基于P2P（點(diǎn)對(duì)點(diǎn)）的。P2P的實(shí)現(xiàn)依賴于客戶端之間的互聯(lián)，但由于NAT與防火墻的存在，客戶端無法直接互聯(lián)，需要coturn服務(wù)器用來穿越NAT網(wǎng)絡(luò)。

架構(gòu)設(shè)計(jì)

本章主要會(huì)介紹基于TableStore的現(xiàn)代IM消息系統(tǒng)的架構(gòu)設(shè)計(jì)，在詳細(xì)介紹架構(gòu)設(shè)計(jì)之前，會(huì)先介紹一種Timeline邏輯模型，來抽象和簡(jiǎn)化對(duì)IM消息同步和存儲(chǔ)模型的理解。理解了Timeline模型后，會(huì)介紹如何基于此模型對(duì)消息的同步以及存儲(chǔ)進(jìn)行建模?；赥imeline模型，在實(shí)現(xiàn)消息同步和存儲(chǔ)時(shí)還會(huì)有各方面的技術(shù)權(quán)衡，例如如何對(duì)消息同步常見的讀擴(kuò)散和寫擴(kuò)散兩種模型進(jìn)行對(duì)比和選擇，以及針對(duì)Timeline模型的特征如何來選擇底層數(shù)據(jù)庫。

傳統(tǒng)架構(gòu) vs 現(xiàn)代架構(gòu)

上圖是消息系統(tǒng)傳統(tǒng)架構(gòu)與現(xiàn)代架構(gòu)的簡(jiǎn)單對(duì)比。

傳統(tǒng)架構(gòu)下，消息是先同步后存儲(chǔ)。對(duì)于在線的用戶，消息會(huì)直接實(shí)時(shí)同步到在線的接收方，消息同步成功后，并不會(huì)進(jìn)行持久化。而對(duì)于離線的用戶或者消息無法實(shí)時(shí)同步成功時(shí)，消息會(huì)持久化到離線庫，當(dāng)接收方重新連接后，會(huì)從離線庫拉取所有未讀消息。當(dāng)離線庫中的消息成功同步到接收方后，消息會(huì)從離線庫中刪除。傳統(tǒng)的消息系統(tǒng)，服務(wù)端的主要工作是維護(hù)發(fā)送方和接收方的連接狀態(tài)，并提供在線消息同步和離線消息緩存的能力，保證消息一定能夠從發(fā)送方傳遞到接收方。服務(wù)端不會(huì)對(duì)消息進(jìn)行持久化，所以也無法支持消息漫游。

現(xiàn)代架構(gòu)下，消息是先存儲(chǔ)后同步。先存儲(chǔ)后同步的好處是，如果接收方確認(rèn)接收到了消息，那這條消息一定是已經(jīng)在云端保存了。并且消息會(huì)有兩個(gè)庫來保存，一個(gè)是消息存儲(chǔ)庫，用于全量保存所有會(huì)話的消息，主要用于支持消息漫游。另一個(gè)是消息同步庫，主要用于接收方的多端同步。消息從發(fā)送方發(fā)出后，經(jīng)過服務(wù)端轉(zhuǎn)發(fā)，服務(wù)端會(huì)先將消息保存到消息存儲(chǔ)庫，后保存到消息同步庫。完成消息的持久化保存后，對(duì)于在線的接收方，會(huì)直接選擇在線推送。但在線推送并不是一個(gè)必須路徑，只是一個(gè)更優(yōu)的消息傳遞路徑。對(duì)于在線推送失敗或者離線的接收方，會(huì)有另外一個(gè)統(tǒng)一的消息同步方式。接收方會(huì)主動(dòng)的向服務(wù)端拉取所有未同步消息，但接收方何時(shí)來同步以及會(huì)在哪些端來同步消息對(duì)服務(wù)端來說是未知的，所以要求服務(wù)端必須保存所有需要同步到接收方的消息，這是消息同步庫的主要作用。對(duì)于新的同步設(shè)備，會(huì)有消息漫游的需求，這是消息存儲(chǔ)庫的主要作用，在消息存儲(chǔ)庫中，可以拉取任意會(huì)話的全量歷史消息。

以上是傳統(tǒng)架構(gòu)和現(xiàn)代架構(gòu)的一個(gè)簡(jiǎn)單的對(duì)比，現(xiàn)代架構(gòu)上整個(gè)消息的同步和存儲(chǔ)流程，并沒有變復(fù)雜太多，但是其能實(shí)現(xiàn)多端同步以及消息漫游?，F(xiàn)代架構(gòu)中最核心的就是兩個(gè)消息庫『消息同步庫』和『消息存儲(chǔ)庫』，是消息同步和存儲(chǔ)最核心的基礎(chǔ)。而本篇文章接下來的部分，都是圍繞這兩個(gè)庫的設(shè)計(jì)和實(shí)現(xiàn)來展開。

Timeline模型

在分析『消息同步庫』和『消息存儲(chǔ)庫』的設(shè)計(jì)和實(shí)現(xiàn)之前，在本章會(huì)先介紹一個(gè)邏輯模型-Timeline。Timeline模型會(huì)幫助我們簡(jiǎn)化對(duì)消息同步和存儲(chǔ)模型的理解，而消息庫的設(shè)計(jì)和實(shí)現(xiàn)也是圍繞Timeline的特性和需求來展開。

如圖是Timeline模型的一個(gè)抽象表述，Timeline可以簡(jiǎn)單理解為是一個(gè)消息隊(duì)列，但這個(gè)消息隊(duì)列有如下特性：

每個(gè)消息擁有一個(gè)順序ID（SeqId），在隊(duì)列后面的消息的SeqId一定比前面的消息的SeqId大，也就是保證SeqId一定是增長的，但是不要求嚴(yán)格遞增。

新的消息永遠(yuǎn)在尾部添加，保證新的消息的SeqId永遠(yuǎn)比已經(jīng)存在隊(duì)列中的消息都大。

可根據(jù)SeqId隨機(jī)定位到具體的某條消息進(jìn)行讀取，也可以任意讀取某個(gè)給定范圍內(nèi)的所有消息。

有了這些特性后，消息的同步可以拿Timeline來很簡(jiǎn)單的實(shí)現(xiàn)。圖中的例子中，消息發(fā)送方是A，消息接收方是B，同時(shí)B存在多個(gè)接收端，分別是B1、B2和B3。A向B發(fā)送消息，消息需要同步到B的多個(gè)端，待同步的消息通過一個(gè)Timeline來進(jìn)行交換。A向B發(fā)送的所有消息，都會(huì)保存在這個(gè)Timeline中，B的每個(gè)接收端都是獨(dú)立的從這個(gè)Timeline中拉取消息。每個(gè)接收端同步完畢后，都會(huì)在本地記錄下最新同步到的消息的SeqId，即最新的一個(gè)位點(diǎn)，作為下次消息同步的起始位點(diǎn)。服務(wù)端不會(huì)保存各個(gè)端的同步狀態(tài)，各個(gè)端均可以在任意時(shí)間從任意點(diǎn)開始拉取消息。

消息漫游也是基于Timeline，和消息同步唯一的區(qū)別是，消息漫游要求服務(wù)端能夠?qū)imeline內(nèi)的所有數(shù)據(jù)進(jìn)行持久化。

基于Timeline，從邏輯模型上能夠很簡(jiǎn)單的理解在服務(wù)端如何去實(shí)現(xiàn)消息同步和存儲(chǔ)，并支持多端同步和消息漫游這些高級(jí)功能。落地到實(shí)現(xiàn)的難點(diǎn)主要在如何將邏輯模型映射到物理模型，Timeline的實(shí)現(xiàn)對(duì)數(shù)據(jù)庫會(huì)有哪些要求？我們應(yīng)該選擇何種數(shù)據(jù)庫去實(shí)現(xiàn)？這些是接下來會(huì)討論到的問題。

消息存儲(chǔ)模型

如圖是基于Timeline的消息存儲(chǔ)模型，消息存儲(chǔ)要求每個(gè)會(huì)話都對(duì)應(yīng)一個(gè)獨(dú)立的Timeline。如圖例子所示，A與B/C/D/E/F均發(fā)生了會(huì)話，每個(gè)會(huì)話對(duì)應(yīng)一個(gè)獨(dú)立的Timeline，每個(gè)Timeline內(nèi)存有這個(gè)會(huì)話中的所有消息，服務(wù)端會(huì)對(duì)每個(gè)Timeline進(jìn)行持久化。服務(wù)端能夠?qū)λ袝?huì)話Timeline中的全量消息進(jìn)行持久化，也就擁有了消息漫游的能力。

消息同步模型

消息同步模型會(huì)比消息存儲(chǔ)模型稍復(fù)雜一些，消息的同步一般有讀擴(kuò)散和寫擴(kuò)散兩種不同的方式，分別對(duì)應(yīng)不同的Timeline物理模型。

如圖是讀擴(kuò)散和寫擴(kuò)散兩種不同同步模式下對(duì)應(yīng)的不同的Timeline模型，按圖中的示例，A作為消息接收者，其與B/C/D/E/F發(fā)生了會(huì)話，每個(gè)會(huì)話中的新的消息都需要同步到A的某個(gè)端，看下讀擴(kuò)散和寫擴(kuò)散兩種模式下消息如何做同步。

讀擴(kuò)散：消息存儲(chǔ)模型中，每個(gè)會(huì)話的Timeline中保存了這個(gè)會(huì)話的全量消息。讀擴(kuò)散的消息同步模式下，每個(gè)會(huì)話中產(chǎn)生的新的消息，只需要寫一次到其用于存儲(chǔ)的Timeline中，接收端從這個(gè)Timeline中拉取新的消息。優(yōu)點(diǎn)是消息只需要寫一次，相比寫擴(kuò)散的模式，能夠大大降低消息寫入次數(shù)，特別是在群消息這種場(chǎng)景下。但其缺點(diǎn)也比較明顯，接收端去同步消息的邏輯會(huì)相對(duì)復(fù)雜和低效。接收端需要對(duì)每個(gè)會(huì)話都拉取一次才能獲取全部消息，讀被大大的放大，并且會(huì)產(chǎn)生很多無效的讀，因?yàn)椴⒉皇敲總€(gè)會(huì)話都會(huì)有新消息產(chǎn)生。

寫擴(kuò)散：寫擴(kuò)散的消息同步模式，需要有一個(gè)額外的Timeline來專門用于消息同步，通常是每個(gè)接收端都會(huì)擁有一個(gè)獨(dú)立的同步Timeline，用于存放需要向這個(gè)接收端同步的所有消息。每個(gè)會(huì)話中的消息，會(huì)產(chǎn)生多次寫，除了寫入用于消息存儲(chǔ)的會(huì)話Timeline，還需要寫入需要同步到的接收端的同步Timeline。在個(gè)人與個(gè)人的會(huì)話中，消息會(huì)被額外寫兩次，除了寫入這個(gè)會(huì)話的存儲(chǔ)Timeline，還需要寫入?yún)⑴c這個(gè)會(huì)話的兩個(gè)接收者的同步Timeline。而在群這個(gè)場(chǎng)景下，寫入會(huì)被更加的放大，如果這個(gè)群擁有N個(gè)參與者，那每條消息都需要額外的寫N次。寫擴(kuò)散同步模式的優(yōu)點(diǎn)是，在接收端消息同步邏輯會(huì)非常簡(jiǎn)單，只需要從其同步Timeline中讀取一次即可，大大降低了消息同步所需的讀的壓力。其缺點(diǎn)就是消息寫入會(huì)被放大，特別是針對(duì)群這種場(chǎng)景。

在IM這種應(yīng)用場(chǎng)景下，通常會(huì)選擇寫擴(kuò)散這種消息同步模式。IM場(chǎng)景下，一條消息只會(huì)產(chǎn)生一次，但是會(huì)被讀取多次，是典型的讀多寫少的場(chǎng)景，消息的讀寫比例大概是10:1。若使用讀擴(kuò)散同步模式，整個(gè)系統(tǒng)的讀寫比例會(huì)被放大到100:1。一個(gè)優(yōu)化的好的系統(tǒng)，必須從設(shè)計(jì)上去平衡這種讀寫壓力，避免讀或?qū)懭我庖痪S觸碰到天花板。所以IM系統(tǒng)這類場(chǎng)景下，通常會(huì)應(yīng)用寫擴(kuò)散這種同步模式，來平衡讀和寫，將100:1的讀寫比例平衡到30:30。當(dāng)然寫擴(kuò)散這種同步模式，還需要處理一些極端場(chǎng)景，例如萬人大群。針對(duì)這種極端寫擴(kuò)散的場(chǎng)景，會(huì)退化到使用讀擴(kuò)散。一個(gè)簡(jiǎn)單的IM系統(tǒng)，通常會(huì)在產(chǎn)品層面限制這種大群的存在，而對(duì)于一個(gè)高級(jí)的IM系統(tǒng)，會(huì)采用讀寫擴(kuò)散混合的同步模式，來滿足這類產(chǎn)品的需求。