摘要： 前言 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)成長為一個(gè)生態(tài)型產(chǎn)品，但其核心功能還是IM。

前言

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)成長為一個(gè)生態(tài)型產(chǎn)品，但其核心功能還是IM。還有一些非以IM系統(tǒng)為核心的應(yīng)用，最典型的如一些在線游戲、社交應(yīng)用，IM也是其重要的功能模塊?？梢哉f，帶有社交屬性的應(yīng)用，IM功能一定是必不可少的。

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ī)模。從功能上來說，一般至少要支持在線和離線推送，高級(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ǔ)，百萬TPS以及毫秒級(jí)延遲的消息同步能力。

架構(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)行建模。基于Timeline模型，在實(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)品的需求。

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

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

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

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

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

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

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

表結(jié)構(gòu)設(shè)計(jì)能夠滿足Timeline模型的功能要求：不要求關(guān)系模型，能夠?qū)崿F(xiàn)隊(duì)列模型，并能夠支持生成自增的SeqId。
能夠支持高并發(fā)寫和范圍讀，規(guī)模在十萬級(jí)TPS。
能夠保存海量數(shù)據(jù)，百TB級(jí)。
能夠?yàn)閿?shù)據(jù)定義生命周期。
阿里云表格存儲(chǔ)（TableStore）是基于LSM存儲(chǔ)引擎的分布式NoSQL數(shù)據(jù)庫，支持百萬TPS高并發(fā)讀寫，PB級(jí)數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)支持TTL，能夠很好的滿足以上需求，并且支持自增列，能夠非常完美的設(shè)計(jì)和實(shí)現(xiàn)Timeline的物理模型。

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

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

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

<dependency><groupId>com.aliyun.openservices</groupId><artifactId>tablestore</artifactId><version>4.3.1</version> </dependency>

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

public static void main(String[] args) {String endpoint = "<endpoint>";String accessId = "<access_id>";String accessKey = "<access_key>";String instanceName = "<instance_name>";SyncClient client = new SyncClient(endpoint, accessId, accessKey, instanceName);String pushTable = "PushTable";String storeTable = "StoreTable";createTimelineTable(client, pushTable);createTimelineTable(client, storeTable);client.shutdown();}private static void createTimelineTable(SyncClient client, String tableName) {TableMeta tableMeta = new TableMeta(tableName);tableMeta.addPrimaryKeyColumn("timeline_id", PrimaryKeyType.STRING);tableMeta.addAutoIncrementPrimaryKeyColumn("seq_id");TableOptions options = new TableOptions();options.setMaxVersions(1);options.setTimeToLive(-1); // 配置消息永久保留CreateTableRequest request = new CreateTableRequest(tableMeta, options);client.createTable(request);}

以上是創(chuàng)建Timeline表的示例代碼，總共需要?jiǎng)?chuàng)建兩張表，一張表作為消息同步庫，名稱為『PushTable』，另一張表作為消息存儲(chǔ)庫，名稱為『StoreTable』。

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

public static void main(String[] args) {String endpoint = "<endpoint>";String accessId = "<access_id>";String accessKey = "<access_key>";String instanceName = "<instance_name>";SyncClient client = new SyncClient(endpoint, accessId, accessKey, instanceName);String pushTable = "PushTable";String storeTable = "StoreTable";String groupName = "TableStore(釘釘號(hào)：11789671)";List<String> groupMembers = Arrays.asList("A", "B", "C", "D", "E");// 群產(chǎn)生新的消息，并且推送給所有的群成員pushGroupMessages(client, pushTable, storeTable, groupName, groupMembers, "Hello World!");pushGroupMessages(client, pushTable, storeTable, groupName, groupMembers, "Hello Alibaba!");pushGroupMessages(client, pushTable, storeTable, groupName, groupMembers, "Hello Aliyun!");pushGroupMessages(client, pushTable, storeTable, groupName, groupMembers, "Hello TableStore!");pushGroupMessages(client, pushTable, storeTable, groupName, groupMembers, "Bye!");client.shutdown();}private static void pushGroupMessages(SyncClient client, String pushTable, String storeTable, String groupName, List<String> groupMembers, String message) {// 先將群消息持久化到存儲(chǔ)TimelinewriteMessage(client, storeTable, groupName, message);// 通過寫擴(kuò)散的模式將群消息同步到所有的群成員for (String groupMember : groupMembers) {writeMessage(client, pushTable, groupMember, message);}}private static void writeMessage(SyncClient client, String timelineTable, String timelineId, String message) {PrimaryKey primaryKey = PrimaryKeyBuilder.createPrimaryKeyBuilder().addPrimaryKeyColumn("timeline_id", PrimaryKeyValue.fromString(timelineId)).addPrimaryKeyColumn("seq_id", PrimaryKeyValue.AUTO_INCREMENT).build();RowPutChange rowChange = new RowPutChange(timelineTable, primaryKey);rowChange.addColumn("message", ColumnValue.fromString(message));PutRowRequest request = new PutRowRequest(rowChange);client.putRow(request);}

以上是模擬一個(gè)群內(nèi)消息同步和存儲(chǔ)的示例代碼。群名稱為『TableStore(釘釘號(hào)：11789671)』，群內(nèi)成員有『A, B, C, D, E』。群內(nèi)新的消息，需要先存儲(chǔ)到群的存儲(chǔ)Timeline（Timeline ID為群名稱），之后需要以寫擴(kuò)散的模式推送到群內(nèi)每個(gè)成員的同步Timeline（以群成員名稱作為Timeline ID）。

public static void main(String[] args) {String endpoint = "<endpoint>";String accessId = "<access_id>";String accessKey = "<access_key>";String instanceName = "<instance_name>";SyncClient client = new SyncClient(endpoint, accessId, accessKey, instanceName);String pushTable = "PushTable";String storeTable = "StoreTable";String groupName = "TableStore(釘釘號(hào)：11789671)";List<String> groupMembers = Arrays.asList("A", "B", "C", "D", "E");// 某個(gè)群成員同步群消息List<String> messages = syncMessages(client, pushTable, "A", 0);for (String message : messages) {System.out.println(message);}// 某個(gè)群成員查看該群所有的歷史消息messages = syncMessages(client, storeTable, groupName, 0);for (String message : messages) {System.out.println(message);}client.shutdown();}private static List<String> syncMessages(SyncClient client, String timelineTable, String timelineId, long seqId) {RangeIteratorParameter param = new RangeIteratorParameter(timelineTable);PrimaryKey startKey = PrimaryKeyBuilder.createPrimaryKeyBuilder().addPrimaryKeyColumn("timeline_id", PrimaryKeyValue.fromString(timelineId)).addPrimaryKeyColumn("seq_id", PrimaryKeyValue.fromLong(seqId)).build();param.setInclusiveStartPrimaryKey(startKey);PrimaryKey endKey = PrimaryKeyBuilder.createPrimaryKeyBuilder().addPrimaryKeyColumn("timeline_id", PrimaryKeyValue.fromString(timelineId)).addPrimaryKeyColumn("seq_id", PrimaryKeyValue.INF_MAX).build();param.setExclusiveEndPrimaryKey(endKey);param.setMaxVersions(1);Iterator<Row> iter = client.createRangeIterator(param);List<String> messages = new ArrayList<String>();while (iter.hasNext()) {Row row = iter.next();messages.add(row.getLatestColumn("message").getValue().asString());}return messages;}

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

后記

這篇文章主要介紹了現(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自增。

TableStore(表格存儲(chǔ))是阿里云自主研發(fā)的專業(yè)級(jí)分布式NoSQL數(shù)據(jù)庫，是基于共享存儲(chǔ)的高性能、低成本、易擴(kuò)展、全托管的半結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)平臺(tái)，支撐互聯(lián)網(wǎng)和物聯(lián)網(wǎng)數(shù)據(jù)的高效計(jì)算與分析。IM系統(tǒng)的消息推送和存儲(chǔ)場(chǎng)景，是TableStore在社交領(lǐng)域的重要應(yīng)用之一。

基于Timeline的消息存儲(chǔ)和推送模型，將不光應(yīng)用在IM消息系統(tǒng)中，還可應(yīng)用在例如Feeds流、實(shí)時(shí)消息同步、直播彈幕等場(chǎng)景。在Feeds流場(chǎng)景下，我們也有了比較深入的研究，可以參考《如何打造千萬級(jí)Feeds流系統(tǒng)》這篇文章。而在其他更多的場(chǎng)景下，我們將會(huì)有更多的深入研究。

作者：木洛

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的现代IM系统中消息推送和存储架构的实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。