前言

IM全稱是『Instant Messaging』，中文名是即時(shí)通訊。在這個(gè)高度信息化的移動(dòng)互聯(lián)網(wǎng)時(shí)代，生活中IM類產(chǎn)品已經(jīng)成為必備品，比較有名的如釘釘、微信、QQ等以IM為核心功能的產(chǎn)品。當(dāng)然目前微信已經(jīng)成長(zhǎng)為一個(gè)生態(tài)型產(chǎn)品，但其核心功能還是IM。還有一些非以IM系統(tǒng)為核心的應(yīng)用，最典型的如一些在線游戲、社交應(yīng)用，IM也是其重要的功能模塊。可以說(shuō)，帶有社交屬性的應(yīng)用，IM功能一定是必不可少的。

[[210948]]

IM系統(tǒng)在互聯(lián)網(wǎng)初期即存在，其基礎(chǔ)技術(shù)架構(gòu)在這十幾年的發(fā)展中更新迭代多次，從早期的CS、P2P架構(gòu)，到現(xiàn)在后臺(tái)已經(jīng)演變?yōu)橐粋€(gè)復(fù)雜的分布式系統(tǒng)，涉及移動(dòng)端、網(wǎng)絡(luò)、安全和存儲(chǔ)等技術(shù)的方方面面。其支撐的規(guī)模也從早期的少量日活，到現(xiàn)在微信這個(gè)巨頭***公布的達(dá)到9億的日活的體量。

IM系統(tǒng)中最核心的部分是消息系統(tǒng)，消息系統(tǒng)中最核心的功能是消息的同步和存儲(chǔ)：

• 消息的同步：將消息完整的、快速的從發(fā)送方傳遞到接收方，就是消息的同步。消息同步系統(tǒng)最重要的衡量指標(biāo)就是消息傳遞的實(shí)時(shí)性、完整性以及能支撐的消息規(guī)模。從功能上來(lái)說(shuō)，一般至少要支持在線和離線推送，高級(jí)的IM系統(tǒng)還支持『多端同步』。
• 消息的存儲(chǔ)：消息存儲(chǔ)即消息的持久化保存，這里不是指消息在客戶端本地的保存，而是指云端的保存，功能上對(duì)應(yīng)的就是『消息漫游』?！合⒙巍坏暮锰幨强梢詫?shí)現(xiàn)賬號(hào)在任意端登陸查看所有歷史消息，這也是高級(jí)IM系統(tǒng)特有的功能之一。

本篇文章內(nèi)容主要涉及IM系統(tǒng)中的消息系統(tǒng)架構(gòu)，會(huì)介紹一種基于TableStore構(gòu)建的消息同步以及存儲(chǔ)系統(tǒng)的架構(gòu)實(shí)現(xiàn)，能夠支持消息系統(tǒng)中的高級(jí)特性『多端同步』以及『消息漫游』。在性能和規(guī)模上，能夠做到全量消息云端存儲(chǔ)，百萬(wàn)TPS以及毫秒級(jí)延遲的消息同步能力。

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

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

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

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

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

Timeline模型

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

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

• 每個(gè)消息擁有一個(gè)順序ID（SeqId），在隊(duì)列后面的消息的SeqId一定比前面的消息的SeqId大，也就是保證SeqId一定是增長(zhǎng)的，但是不要求嚴(yán)格遞增。
• 新的消息永遠(yuǎn)在尾部添加，保證新的消息的SeqId永遠(yuǎn)比已經(jīng)存在隊(duì)列中的消息都大。
• 可根據(jù)SeqId隨機(jī)定位到具體的某條消息進(jìn)行讀取，也可以任意讀取某個(gè)給定范圍內(nèi)的所有消息。

有了這些特性后，消息的同步可以拿Timeline來(lái)很簡(jiǎn)單的實(shí)現(xiàn)。圖中的例子中，消息發(fā)送方是A，消息接收方是B，同時(shí)B存在多個(gè)接收端，分別是B1、B2和B3。A向B發(fā)送消息，消息需要同步到B的多個(gè)端，待同步的消息通過(guò)一個(gè)Timeline來(lái)進(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)開(kāi)始拉取消息。

消息漫游也是基于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ù)庫(kù)會(huì)有哪些要求？我們應(yīng)該選擇何種數(shù)據(jù)庫(kù)去實(shí)現(xiàn)？這些是接下來(lái)會(huì)討論到的問(wèn)題。

消息存儲(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ò)散和寫(xiě)擴(kuò)散兩種不同的方式，分別對(duì)應(yīng)不同的Timeline物理模型。

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

• 讀擴(kuò)散：消息存儲(chǔ)模型中，每個(gè)會(huì)話的Timeline中保存了這個(gè)會(huì)話的全量消息。讀擴(kuò)散的消息同步模式下，每個(gè)會(huì)話中產(chǎn)生的新的消息，只需要寫(xiě)一次到其用于存儲(chǔ)的Timeline中，接收端從這個(gè)Timeline中拉取新的消息。優(yōu)點(diǎn)是消息只需要寫(xiě)一次，相比寫(xiě)擴(kuò)散的模式，能夠大大降低消息寫(xiě)入次數(shù)，特別是在群消息這種場(chǎng)景下。但其缺點(diǎn)也比較明顯，接收端去同步消息的邏輯會(huì)相對(duì)復(fù)雜和低效。接收端需要對(duì)每個(gè)會(huì)話都拉取一次才能獲取全部消息，讀被大大的放大，并且會(huì)產(chǎn)生很多無(wú)效的讀，因?yàn)椴⒉皇敲總€(gè)會(huì)話都會(huì)有新消息產(chǎn)生。
• 寫(xiě)擴(kuò)散：寫(xiě)擴(kuò)散的消息同步模式，需要有一個(gè)額外的Timeline來(lái)專門(mén)用于消息同步，通常是每個(gè)接收端都會(huì)擁有一個(gè)獨(dú)立的同步Timeline，用于存放需要向這個(gè)接收端同步的所有消息。每個(gè)會(huì)話中的消息，會(huì)產(chǎn)生多次寫(xiě)，除了寫(xiě)入用于消息存儲(chǔ)的會(huì)話Timeline，還需要寫(xiě)入需要同步到的接收端的同步Timeline。在個(gè)人與個(gè)人的會(huì)話中，消息會(huì)被額外寫(xiě)兩次，除了寫(xiě)入這個(gè)會(huì)話的存儲(chǔ)Timeline，還需要寫(xiě)入?yún)⑴c這個(gè)會(huì)話的兩個(gè)接收者的同步Timeline。而在群這個(gè)場(chǎng)景下，寫(xiě)入會(huì)被更加的放大，如果這個(gè)群擁有N個(gè)參與者，那每條消息都需要額外的寫(xiě)N次。寫(xiě)擴(kuò)散同步模式的優(yōu)點(diǎn)是，在接收端消息同步邏輯會(huì)非常簡(jiǎn)單，只需要從其同步Timeline中讀取一次即可，大大降低了消息同步所需的讀的壓力。其缺點(diǎn)就是消息寫(xiě)入會(huì)被放大，特別是針對(duì)群這種場(chǎng)景。

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

消息庫(kù)設(shè)計(jì)

基于Timeline模型，以及Timeline模型在消息存儲(chǔ)和消息同步的應(yīng)用，我們看下消息同步庫(kù)和消息存儲(chǔ)庫(kù)的設(shè)計(jì)。

如圖是基于Timeline的消息庫(kù)設(shè)計(jì)。

• 消息同步庫(kù)：消息同步庫(kù)用于存儲(chǔ)所有用于消息同步的Timeline，每個(gè)Timeline對(duì)應(yīng)一個(gè)接收端，主要用作寫(xiě)擴(kuò)散模式的消息同步。這個(gè)庫(kù)不需要***保留所有需要同步的消息，因?yàn)橄⒃谕降剿卸撕笃渖芷诰涂梢越Y(jié)束，就可以被回收。但是如前面所介紹的，一個(gè)實(shí)現(xiàn)簡(jiǎn)單的多端同步消息系統(tǒng)，在服務(wù)端不會(huì)保存有所有端的同步狀態(tài)，而是依賴端自己主動(dòng)來(lái)做同步。所以服務(wù)端不知道消息何時(shí)可以回收，通常的做法是為這個(gè)庫(kù)里的消息設(shè)定一個(gè)固定的生命周期，例如一周或者一個(gè)月，生命周期結(jié)束可被淘汰。
• 消息存儲(chǔ)庫(kù)：消息存儲(chǔ)庫(kù)用于存儲(chǔ)所有會(huì)話的Timeline，每個(gè)Timeline包含了一個(gè)會(huì)話中的所有消息。這個(gè)庫(kù)主要用于消息漫游時(shí)拉取某個(gè)會(huì)話的所有歷史消息，也用于讀擴(kuò)散模式的消息同步。

消息同步庫(kù)和消息存儲(chǔ)庫(kù)，對(duì)數(shù)據(jù)庫(kù)有不同的要求，如何對(duì)數(shù)據(jù)庫(kù)做選型，在下面會(huì)討論。

數(shù)據(jù)庫(kù)選型

消息系統(tǒng)最核心的兩個(gè)庫(kù)是消息同步庫(kù)和消息存儲(chǔ)庫(kù)，兩個(gè)庫(kù)對(duì)數(shù)據(jù)庫(kù)有不同的要求：

總結(jié)下來(lái)，對(duì)數(shù)據(jù)庫(kù)的要求有如下幾點(diǎn)：

1. 表結(jié)構(gòu)設(shè)計(jì)能夠滿足Timeline模型的功能要求：不要求關(guān)系模型，能夠?qū)崿F(xiàn)隊(duì)列模型，并能夠支持生成自增的SeqId。

2. 能夠支持高并發(fā)寫(xiě)和范圍讀，規(guī)模在十萬(wàn)級(jí)TPS。

3. 能夠保存海量數(shù)據(jù)，百TB級(jí)。

4. 能夠?yàn)閿?shù)據(jù)定義生命周期。

阿里云表格存儲(chǔ)（TableStore）是基于LSM存儲(chǔ)引擎的分布式NoSQL數(shù)據(jù)庫(kù)，支持百萬(wàn)TPS高并發(fā)讀寫(xiě)，PB級(jí)數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)支持TTL，能夠很好的滿足以上需求，并且支持自增列，能夠非常***的設(shè)計(jì)和實(shí)現(xiàn)Timeline的物理模型。

架構(gòu)實(shí)現(xiàn)

本章會(huì)以一段非常精簡(jiǎn)的代碼，來(lái)展示如何基于TableStore實(shí)現(xiàn)Timeline模型，并基于Timeline模型進(jìn)行消息存儲(chǔ)和推送。

這篇文章中給出的代碼，主要目的是為了演示如何能夠?qū)崿F(xiàn)一個(gè)精簡(jiǎn)Timeline的最基本功能。馬上我們會(huì)推出一個(gè)完整的Timeline Library，來(lái)將基于Timeline進(jìn)行消息存儲(chǔ)和推送的代碼的開(kāi)發(fā)變得無(wú)比簡(jiǎn)單。

所有示例代碼基于如下SDK版本：

表結(jié)構(gòu)設(shè)計(jì)

以上是創(chuàng)建Timeline表的示例代碼，總共需要?jiǎng)?chuàng)建兩張表，一張表作為消息同步庫(kù)。

推送和存儲(chǔ)實(shí)現(xiàn)

以上是模擬一個(gè)群內(nèi)消息同步和存儲(chǔ)的示例代碼。

以上是拉取群內(nèi)歷史消息以及某個(gè)群成員進(jìn)行消息同步的示例代碼，主要邏輯在syncMessages函數(shù)內(nèi)。示例代碼中，拉取消息都是從seq_id為0開(kāi)始，0為T(mén)ableStore自增列中最小值，所以代表了從最小的一個(gè)位點(diǎn)開(kāi)始拉取消息，即拉取全量消息。

后記

這篇文章主要介紹了現(xiàn)代IM系統(tǒng)中消息推送和存儲(chǔ)架構(gòu)的實(shí)現(xiàn)，基于邏輯的Timeline模型，我們可以很清晰明了的理解整個(gè)消息推送和存儲(chǔ)的架構(gòu)?；赥ableStore，可以非常簡(jiǎn)單的實(shí)現(xiàn)Timeline模型，其中自增列功能，***的匹配了Timeline模型中所需要的最關(guān)鍵的SeqId自增。