前言
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ò)通信、協(xié)議、安全、存儲(chǔ)和搜索等技術(shù)的方方面面。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ǔ)即消息的持久化保存，傳統(tǒng)消息系統(tǒng)通常只能支持消息在接收端的本地存儲(chǔ)，數(shù)據(jù)基本不具備可靠性�，F(xiàn)代消息系統(tǒng)能支持消息在服務(wù)端的在線存儲(chǔ)，功能上對(duì)應(yīng)的就是『消息漫游』，消息漫游的好處是可以實(shí)現(xiàn)賬號(hào)在任意端登陸查看所有歷史消息。
- 消息的檢索：消息般是文本，所以支持全文檢索也是必備的能力之一。傳統(tǒng)消息系統(tǒng)通常來(lái)說(shuō)也是只能支持消息的本地檢索，基于本地存儲(chǔ)的消息數(shù)據(jù)來(lái)構(gòu)建。而現(xiàn)在消息系統(tǒng)在能支持消息的在線存儲(chǔ)后，也具備了消息的『在線檢索』能力。
本篇文章內(nèi)容主要涉及IM系統(tǒng)中的消息系統(tǒng)架構(gòu)，會(huì)介紹一種基于阿里云表格存儲(chǔ) Tablestore 的 Timeline 模型構(gòu)建的消息系統(tǒng)�；� Tablestore Timeline 構(gòu)建的現(xiàn)代消息系統(tǒng)，能夠同時(shí)支持消息系統(tǒng)的眾多高級(jí)特性，包括『多端同步』、『消息漫游』和『在線檢索』。在性能和規(guī)模上，能夠做到全量消息云端存儲(chǔ)和索引，百萬(wàn) TPS 寫入以及毫秒級(jí)延遲的消息同步和檢索能力。
之后我們會(huì)繼續(xù)發(fā)表兩篇文章，來(lái)更詳細(xì)介紹 Tablestore Timeline 模型概念及使用：
- 模型篇：詳細(xì)介紹 Tablestore Timeline 模型的基本概念和基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，并結(jié)合 IM 系統(tǒng)進(jìn)行基本的建模。
- 實(shí)現(xiàn)篇：會(huì)基于 Tablestore Timeline 實(shí)現(xiàn)一個(gè)具備『多端同步』、『消息漫游』和『在線檢索』這些高級(jí)功能的簡(jiǎn)易IM系統(tǒng)，并共享我們的源代碼。
傳統(tǒng)架構(gòu) vs 現(xiàn)代架構(gòu)
傳統(tǒng)架構(gòu)下，消息是先同步后存儲(chǔ)。對(duì)于在線的用戶，消息會(huì)直接實(shí)時(shí)同步到在線的接收方，消息同步成功后，并不會(huì)在服務(wù)端持久化。而對(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ú)法支持消息漫游。消息的持久化存儲(chǔ)及索引同樣只能在接收端本地實(shí)現(xiàn)，數(shù)據(jù)可靠性極低。
現(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ì)話的全量歷史消息。消息檢索的實(shí)現(xiàn)依賴于對(duì)消息存儲(chǔ)庫(kù)內(nèi)消息的索引，通常是一個(gè)近實(shí)時(shí)（NRT，near real time）的索引構(gòu)建過(guò)程，這個(gè)索引同樣是在線的。
以上就是傳統(tǒng)架構(gòu)和現(xiàn)代架構(gòu)的一個(gè)簡(jiǎn)單的對(duì)比，現(xiàn)代架構(gòu)上整個(gè)消息的同步、存儲(chǔ)和索引流程，并沒(méi)有變復(fù)雜太多�，F(xiàn)代架構(gòu)的實(shí)現(xiàn)本質(zhì)上是把傳統(tǒng)架構(gòu)內(nèi)本地存儲(chǔ)和索引都搬到云上，最大挑戰(zhàn)是需要集中管理全量消息的存儲(chǔ)和索引，帶來(lái)的好處是能實(shí)現(xiàn)多端同步、消息漫游以及在線檢索�？梢钥吹浆F(xiàn)代架構(gòu)中最核心的就是兩個(gè)消息庫(kù)『消息同步庫(kù)』和『消息存儲(chǔ)庫(kù)』，以及對(duì)『消息存儲(chǔ)庫(kù)』的『消息索引』的實(shí)現(xiàn)，接下來(lái)我們逐步拆解這幾個(gè)核心的設(shè)計(jì)和實(shí)現(xiàn)。
基礎(chǔ)模型
在深入講解消息系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)之前，需要對(duì)消息系統(tǒng)內(nèi)的幾個(gè)基本概念和基礎(chǔ)模型有一個(gè)理解。網(wǎng)上分析的很多的不同類型的消息系統(tǒng)實(shí)現(xiàn)，實(shí)現(xiàn)差異上主要在消息同步和存儲(chǔ)的方案上，在消息的數(shù)據(jù)模型上其實(shí)有很大的共性。圍繞數(shù)據(jù)同步模型的討論主要在『讀擴(kuò)散』、『寫擴(kuò)散』和『混合模式』這三種方案，目前還沒(méi)有更多的選擇。而對(duì)于數(shù)據(jù)模型的抽象，還沒(méi)有一個(gè)標(biāo)準(zhǔn)的定義。
本章節(jié)會(huì)介紹下表格存儲(chǔ) Tablestore 提出的 Timeline 模型，這是一個(gè)對(duì)消息系統(tǒng)內(nèi)消息模型的一個(gè)抽象，能簡(jiǎn)化和更好地讓開(kāi)發(fā)者理解消息系統(tǒng)內(nèi)的消息同步和存儲(chǔ)模型，基于此模型我們會(huì)再深入探討消息的同步和存儲(chǔ)的選擇和實(shí)現(xiàn)。
Timeline模型
Timeline是一個(gè)對(duì)消息抽象的邏輯模型，該模型會(huì)幫助我們簡(jiǎn)化對(duì)消息同步和存儲(chǔ)模型的理解，而消息同步庫(kù)和存儲(chǔ)庫(kù)的設(shè)計(jì)和實(shí)現(xiàn)也是圍繞Timeline的特性和需求來(lái)展開(kāi)。
如圖是 Timeline 模型的一個(gè)抽象表述，Timeline 可以簡(jiǎn)單理解為是一個(gè)消息隊(duì)列，但這個(gè)消息隊(duì)列有如下特性：
- 每條消息對(duì)應(yīng)一個(gè)順序ID：每個(gè)消息擁有一個(gè)唯一的順序ID（SequenceId），隊(duì)列消息按 SequenceId 排序。
- 新消息寫入能自動(dòng)分配遞增的順序 ID，保證永遠(yuǎn)插入隊(duì)尾：Timeline 中是根據(jù)同步位點(diǎn)也就是順序 ID 來(lái)同步消息，所以需要保證新寫入的消息數(shù)據(jù)的順序 ID 絕對(duì)不能比已同步的消息的順序 ID 還小，否則會(huì)導(dǎo)致數(shù)據(jù)漏同步，所以需要支持對(duì)新寫入的數(shù)據(jù)自動(dòng)分配比當(dāng)前已存儲(chǔ)的所有消息的順序 ID 更大的順序 ID 。
- 新消息寫入也能自定義順序 ID，滿足自定義排序需求：上面提到的自動(dòng)分配順序 ID，主要是為了滿足消息同步的需求，消息同步要求消息是根據(jù)『已同步』或是『已寫入』的順序來(lái)排序。而消息的存儲(chǔ)，通常要求消息能根據(jù)會(huì)話順序來(lái)排序，會(huì)話順序通常由端的會(huì)話來(lái)決定，而不是服務(wù)端的同步順序來(lái)定，這是兩種順序要求。
- 支持根據(jù)順序 ID 的隨機(jī)定位：可根據(jù) SequenceId 隨機(jī)定位到 Timeline 中的某個(gè)位置，從這個(gè)位置開(kāi)始正序或逆序的讀取消息，也可支持讀取指定順序ID的某條消息。
- 支持對(duì)消息的自定義索引：消息體內(nèi)數(shù)據(jù)根據(jù)業(yè)務(wù)不同會(huì)包含不同的字段， Timeline 需要支持對(duì)不同字段的自定義索引，來(lái)支持對(duì)消息內(nèi)容的全文索引，或者是任意字段的靈活條件組合查詢。
消息同步可以基于 Timeline 很簡(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ì)在本地記錄下最新同步到的消息的SequenceId，即最新的一個(gè)位點(diǎn)，作為下次消息同步的起始位點(diǎn)。服務(wù)端不會(huì)保存各個(gè)端的同步狀態(tài)，各個(gè)端均可以在任意時(shí)間從任意點(diǎn)開(kāi)始拉取消息。
消息存儲(chǔ)也是基于 Timeline 實(shí)現(xiàn)，和消息同步唯一的區(qū)別是，消息存儲(chǔ)要求服務(wù)端能夠?qū)?Timeline 內(nèi)的所有數(shù)據(jù)進(jìn)行持久化，并且消息采用會(huì)話順序來(lái)保存，需要自定義順序 ID。
消息檢索基于 Timeline 提供的消息索引來(lái)實(shí)現(xiàn)，能支持比較靈活的多字段索引，根據(jù)業(yè)務(wù)的不同可有自由度較高的定制。
消息存儲(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ì)話中的所有消息，消息根據(jù)會(huì)話順序排序，服務(wù)端會(huì)對(duì)每個(gè) Timeline 進(jìn)行持久化存儲(chǔ)，也就擁有了消息漫游的能力。
消息同步模型
消息同步模型會(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)生很多無(wú)效的讀，因?yàn)椴⒉皇敲總�(gè)會(huì)話都會(huì)有新消息產(chǎn)生。
- 寫擴(kuò)散：寫擴(kuò)散的消息同步模式，需要有一個(gè)額外的 Timeline 來(lái)專門用于消息同步，通常是每個(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)景。
Timeline 模型不會(huì)對(duì)選擇讀擴(kuò)散還是寫擴(kuò)散做約束，而是能同時(shí)支持兩種模式，因?yàn)楸举|(zhì)上兩種模式的邏輯數(shù)據(jù)模型并無(wú)差別，只是消息數(shù)據(jù)是用一個(gè) Timeline 來(lái)支持多端讀還是復(fù)制到多個(gè) Timeline 來(lái)支持多端讀的問(wèn)題。
針對(duì) IM 這種應(yīng)用場(chǎng)景，消息系統(tǒ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ò)散這種同步模式，來(lái)平衡讀和寫，將100:1的讀寫比例平衡到30:30。當(dāng)然寫擴(kuò)散這種同步模式，還需要處理一些極端場(chǎng)景，例如萬(wàn)人大群。
針對(duì)這種極端寫擴(kuò)散的場(chǎng)景，會(huì)退化到使用讀擴(kuò)散。一個(gè)簡(jiǎn)單的IM系統(tǒng)，通常會(huì)在產(chǎn)品層面限制這種大群的存在，而對(duì)于一個(gè)高級(jí)的IM系統(tǒng)，會(huì)采用讀寫擴(kuò)散混合的同步模式，來(lái)滿足這類產(chǎn)品的需求。采用混合模式，會(huì)根據(jù)數(shù)據(jù)的不同類型和不同的讀寫負(fù)載，來(lái)決定用寫擴(kuò)散還是讀擴(kuò)散。
典型架構(gòu)設(shè)計(jì)
如圖是一個(gè)典型的消息系統(tǒng)架構(gòu)，架構(gòu)中包含幾個(gè)重要組件：
- 端：作為消息的發(fā)送和接收端，通過(guò)連接消息服務(wù)器來(lái)發(fā)送和接收消息。
- 消息服務(wù)器：一組無(wú)狀態(tài)的服務(wù)器，可水平擴(kuò)展，處理消息的發(fā)送和接收請(qǐng)求，連接后端消息系統(tǒng)。
- 消息隊(duì)列：新寫入消息的緩沖隊(duì)列，消息系統(tǒng)的前置消息存儲(chǔ)，用于削峰填谷以及異步消費(fèi)。
- 消息處理：一組無(wú)狀態(tài)的消費(fèi)處理服務(wù)器，用于異步消費(fèi)消息隊(duì)列中的消息數(shù)據(jù)，處理消息的持久化和寫擴(kuò)散同步。
- 消息存儲(chǔ)和索引庫(kù)：持久化存儲(chǔ)消息，每個(gè)會(huì)話對(duì)應(yīng)一個(gè) Timeline 進(jìn)行消息存儲(chǔ)，存儲(chǔ)的消息建立索引來(lái)實(shí)現(xiàn)消息檢索。
- 消息同步庫(kù)：寫擴(kuò)散形式同步消息，每個(gè)用戶的收件箱對(duì)應(yīng)一個(gè) Timeline，同步庫(kù)內(nèi)消息不需要永久保存，通常對(duì)消息設(shè)定一個(gè)生命周期。
新消息會(huì)由端發(fā)出，通常消息體中會(huì)攜帶消息ID（用于去重）、邏輯時(shí)間戳（用于排序）、消息類型（控制消息、圖片消息或者文本消息等）、消息體等內(nèi)容。消息會(huì)先寫入消息隊(duì)列，作為底層存儲(chǔ)的一個(gè)臨時(shí)緩沖區(qū)。消息隊(duì)列中的消息會(huì)由消息處理服務(wù)器消費(fèi)，可以允許亂序消費(fèi)。消息處理服務(wù)器對(duì)消息先存儲(chǔ)后同步，先寫入發(fā)件箱 Timeline （存儲(chǔ)庫(kù)），后寫擴(kuò)散至各個(gè)接收端的收件箱（同步庫(kù)）。消息數(shù)據(jù)寫入存儲(chǔ)庫(kù)后，會(huì)被近實(shí)時(shí)的構(gòu)建索引，索引包括文本消息的全文索引以及多字段索引（發(fā)送方、消息類型等）。
對(duì)于在線的設(shè)備，可以由消息服務(wù)器主動(dòng)推送至在線設(shè)備端。對(duì)于離線設(shè)備，登錄后會(huì)主動(dòng)向服務(wù)端同步消息。每個(gè)設(shè)備會(huì)在本地保留有最新一條消息的順序ID，向服務(wù)端同步該順序ID后的所有消息。
總結(jié)
本篇文章主要介紹了現(xiàn)代 IM 系統(tǒng)中消息系統(tǒng)所需要具備的能力，對(duì)比了傳統(tǒng)架構(gòu)和現(xiàn)代架構(gòu)。為方便接下來(lái)的深入探討，介紹了表格存儲(chǔ) Tablestore 推出的 Timeline 模型，以及在 IM 系統(tǒng)中消息存儲(chǔ)和消息同步模型的基本概念和策略，最后介紹了一個(gè)典型的架構(gòu)設(shè)計(jì)。希望和同仁共同探討、交流。來(lái)源：阿里技術(shù)
