前言

IM全稱是『Instant Messaging』，中文名是即時通訊。在這個高度信息化的移動互聯網時代，生活中IM類產品已經成為必備品，比較有名的如釘釘、微信、QQ等以IM為核心功能的產品。當然目前微信已經成長為一個生態型產品，但其核心功能還是IM。還有一些非以IM系統為核心的應用，最典型的如一些在線遊戲、社交應用，IM也是其重要的功能模塊。可以說，IM系統已經是任何一個帶有社交屬性的應用需要具備的基礎功能，網路上對於這類系統的設計與實現的討論也越來越多。

IM系統在互聯網初期即存在，其基礎技術架構在這十幾年的發展中更新迭代多次，從早期的CS、P2P架構，到現在後台已經演變為一個複雜的分散式系統，涉及移動端、網路通信、協議、安全、存儲和搜索等技術的方方面面。IM系統中最核心的部分是消息系統，消息系統中最核心的功能是消息的同步、存儲和檢索：

• 消息的同步

  ：將消息完整的、快速的從發送方傳遞到接收方，就是消息的同步。消息同步系統最重要的衡量指標就是消息傳遞的實時性、完整性以及能支撐的消息規模。從功能上來說，一般至少要支持在線和離線推送，高級的IM系統還支持『多端同步』。

• 消息的存儲

  ：消息存儲即消息的持久化保存，傳統消息系統通常只能支持消息在接收端的本地存儲，數據基本不具備可靠性。現代消息系統能支持消息在服務端的在線存儲，功能上對應的就是『消息漫遊』，消息漫遊的好處是可以實現賬號在任意端登陸查看所有歷史消息。

• 消息的檢索

  ：消息一般是文本，所以支持全文檢索也是必備的能力之一。傳統消息系統通常來說也是只能支持消息的本地檢索，基於本地存儲的消息數據來構建。而現在消息系統在能支持消息的在線存儲後，也具備了消息的『在線檢索』能力。

本篇文章內容主要涉及IM系統中的消息系統架構，會介紹一種基於阿里雲表格存儲Tablestore的Timeline模型構建的消息系統。基於Tablestore Timeline構建的現代消息系統，能夠同時支持消息系統的眾多高級特性，包括『多端同步』、『消息漫遊』和『在線檢索』。在性能和規模上，能夠做到全量消息雲端存儲和索引，百萬TPS寫入以及毫秒級延遲的消息同步和檢索能力。

之後我們會繼續發表兩篇文章，來更詳細介紹Tablestore Timeline模型概念及使用：

• 模型篇

  ：詳細介紹Tablestore Timeline模型的基本概念和基礎數據結構，並結合IM系統進行基本的建模。

• 實現篇

  ：會基於Tablestore Timeline實現一個具備『多端同步』、『消息漫遊』和『在線檢索』這些高級功能的簡易IM系統，並共享我們的源代碼。

傳統架構 vs 現代架構

傳統架構下，消息是先同步後存儲。對於在線的用戶，消息會直接實時同步到在線的接收方，消息同步成功後，並不會在服務端持久化。而對於離線的用戶或者消息無法實時同步成功時，消息會持久化到離線庫，當接收方重新連接後，會從離線庫拉取所有未讀消息。當離線庫中的消息成功同步到接收方後，消息會從離線庫中刪除。傳統的消息系統，服務端的主要工作是維護髮送方和接收方的連接狀態，並提供在線消息同步和離線消息緩存的能力，保證消息一定能夠從發送方傳遞到接收方。服務端不會對消息進行持久化，所以也無法支持消息漫遊。消息的持久化存儲及索引同樣只能在接收端本地實現，數據可靠性極低。

現代架構下，消息是先存儲後同步。先存儲後同步的好處是，如果接收方確認接收到了消息，那這條消息一定是已經在雲端保存了。並且消息會有兩個庫來保存，一個是消息存儲庫，用於全量保存所有會話的消息，主要用於支持消息漫遊。另一個是消息同步庫，主要用於接收方的多端同步。消息從發送方發出後，經過服務端轉發，服務端會先將消息保存到消息存儲庫，後保存到消息同步庫。完成消息的持久化保存後，對於在線的接收方，會直接選擇在線推送。但在線推送並不是一個必須路徑，只是一個更優的消息傳遞路徑。對於在線推送失敗或者離線的接收方，會有另外一個統一的消息同步方式。接收方會主動的向服務端拉取所有未同步消息，但接收方何時來同步以及會在哪些端來同步消息對服務端來說是未知的，所以要求服務端必須保存所有需要同步到接收方的消息，這是消息同步庫的主要作用。對於新的同步設備，會有消息漫遊的需求，這是消息存儲庫的主要作用，在消息存儲庫中，可以拉取任意會話的全量歷史消息。消息檢索的實現依賴於對消息存儲庫內消息的索引，通常是一個近實時（NRT，near real time）的索引構建過程，這個索引同樣是在線的。

以上就是傳統架構和現代架構的一個簡單的對比，現代架構上整個消息的同步、存儲和索引流程，並沒有變複雜太多。現代架構的實現本質上是把傳統架構內本地存儲和索引都搬到雲上，最大挑戰是需要集中管理全量消息的存儲和索引，帶來的好處是能實現多端同步、消息漫遊以及在線檢索。可以看到現代架構中最核心的就是兩個消息庫『消息同步庫』和『消息存儲庫』，以及對『消息存儲庫』的『消息索引』的實現，接下來我們逐步拆解這幾個核心的設計和實現。

基礎模型

在深入講解消息系統的設計和實現之前，需要對消息系統內的幾個基本概念和基礎模型有一個理解。網上分析的很多的不同類型的消息系統實現，實現差異上主要在消息同步和存儲的方案上，在消息的數據模型上其實有很大的共性。圍繞數據同步模型的討論主要在『讀擴散』、『寫擴散』和『混合模式』這三種方案，目前還沒有更多的選擇。而對於數據模型的抽象，還沒有一個標準的定義。

本章節會介紹下表格存儲Tablestore提出的Timeline模型，這是一個對消息系統內消息模型的一個抽象，能簡化和更好的讓開發者理解消息系統內的消息同步和存儲模型，基於此模型我們會再深入探討消息的同步和存儲的選擇和實現。

Timeline模型

Timeline是一個對消息抽象的邏輯模型，該模型會幫助我們簡化對消息同步和存儲模型的理解，而消息同步庫和存儲庫的設計和實現也是圍繞Timeline的特性和需求來展開。

如圖是Timeline模型的一個抽象表述，Timeline可以簡單理解為是一個消息隊列，但這個消息隊列有如下特性：

• 每條消息對應一個順序ID

  ：每個消息擁有一個唯一的順序ID（SequenceId），隊列消息按SequenceId排序。

• 新消息寫入能自動分配遞增的順序ID，保證永遠插入隊尾

  ：Timeline中是根據同步位點也就是順序ID來同步消息，所以需要保證新寫入的消息數據的順序ID絕對不能比已同步的消息的順序ID還小，否則會導致數據漏同步，所以需要支持對新寫入的數據自動分配比當前已存儲的所有消息的順序ID更大的順序ID。

• 新消息寫入也能自定義順序ID，滿足自定義排序需求

  ：上面提到的自動分配順序ID，主要是為了滿足消息同步的需求，消息同步要求消息是根據『已同步』或是『已寫入』的順序來排序。而消息的存儲，通常要求消息能根據會話順序來排序，會話順序通常由端的會話來決定，而不是服務端的同步順序來定，這是兩種順序要求。

• 支持根據順序ID的隨機定位

  ：可根據SequenceId隨機定位到Timeline中的某個位置，從這個位置開始正序或逆序的讀取消息，也可支持讀取指定順序ID的某條消息。

• 支持對消息的自定義索引

  ：消息體內數據根據業務不同會包含不同的欄位，Timeline需要支持對不同欄位的自定義索引，來支持對消息內容的全文索引，或者是任意欄位的靈活條件組合查詢。

消息同步可以基於Timeline很簡單的實現，圖中的例子中，消息發送方是A，消息接收方是B，同時B存在多個接收端，分別是B1、B2和B3。A向B發送消息，消息需要同步到B的多個端，待同步的消息通過一個Timeline來進行交換。A向B發送的所有消息，都會保存在這個Timeline中，B的每個接收端都是獨立的從這個Timeline中拉取消息。每個接收端同步完畢後，都會在本地記錄下最新同步到的消息的SequenceId，即最新的一個位點，作為下次消息同步的起始位點。服務端不會保存各個端的同步狀態，各個端均可以在任意時間從任意點開始拉取消息。

消息存儲也是基於Timeline實現，和消息同步唯一的區別是，消息存儲要求服務端能夠對Timeline內的所有數據進行持久化，並且消息採用會話順序來保存，需要自定義順序ID。

消息檢索基於Timeline提供的消息索引來實現，能支持比較靈活的多欄位索引，根據業務的不同可有自由度較高的定製。

消息存儲模型

如圖是基於Timeline的消息存儲模型，消息存儲要求每個會話都對應一個獨立的Timeline。如圖例子所示，A與B/C/D/E/F均發生了會話，每個會話對應一個獨立的Timeline，每個Timeline內存有這個會話中的所有消息，消息根據會話順序排序，服務端會對每個Timeline進行持久化存儲，也就擁有了消息漫遊的能力。

消息同步模型

消息同步模型會比消息存儲模型稍複雜一些，消息的同步一般有讀擴散（也叫拉模式）和寫擴散（也叫推模式）兩種不同的方式，分別對應不同的Timeline物理模型。

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

• 讀擴散

  ：消息存儲模型中，每個會話的Timeline中保存了這個會話的全量消息。讀擴散的消息同步模式下，每個會話中產生的新的消息，只需要寫一次到其用於存儲的Timeline中，接收端從這個Timeline中拉取新的消息。優點是消息只需要寫一次，相比寫擴散的模式，能夠大大降低消息寫入次數，特別是在群消息這種場景下。但其缺點也比較明顯，接收端去同步消息的邏輯會相對複雜和低效。接收端需要對每個會話都拉取一次才能獲取全部消息，讀被大大的放大，並且會產生很多無效的讀，因為並不是每個會話都會有新消息產生。

• 寫擴散

  ：寫擴散的消息同步模式，需要有一個額外的Timeline來專門用於消息同步，通常是每個接收端都會擁有一個獨立的同步Timeline（或者叫收件箱），用於存放需要向這個接收端同步的所有消息。每個會話中的消息，會產生多次寫，除了寫入用於消息存儲的會話Timeline，還需要寫入需要同步到的接收端的同步Timeline。在個人與個人的會話中，消息會被額外寫兩次，除了寫入這個會話的存儲Timeline，還需要寫入參與這個會話的兩個接收者的同步Timeline。而在群這個場景下，寫入會被更加的放大，如果這個群擁有N個參與者，那每條消息都需要額外的寫N次。寫擴散同步模式的優點是，在接收端消息同步邏輯會非常簡單，只需要從其同步Timeline中讀取一次即可，大大降低了消息同步所需的讀的壓力。其缺點就是消息寫入會被放大，特別是針對群這種場景。
• Timeline模型不會對選擇讀擴散還是寫擴散做約束，而是能同時支持兩種模式，因為本質上兩種模式的邏輯數據模型並無差別，只是消息數據是用一個Timeline來支持多端讀還是複製到多個Timeline來支持多端讀的問題。

針對IM這種應用場景，消息系統通常會選擇寫擴散這種消息同步模式。IM場景下，一條消息只會產生一次，但是會被讀取多次，是典型的讀多寫少的場景，消息的讀寫比例大概是10:1。若使用讀擴散同步模式，整個系統的讀寫比例會被放大到100:1。一個優化的好的系統，必須從設計上去平衡這種讀寫壓力，避免讀或寫任意一維觸碰到天花板。所以IM系統這類場景下，通常會應用寫擴散這種同步模式，來平衡讀和寫，將100:1的讀寫比例平衡到30:30。當然寫擴散這種同步模式，還需要處理一些極端場景，例如萬人大群。針對這種極端寫擴散的場景，會退化到使用讀擴散。一個簡單的IM系統，通常會在產品層面限制這種大群的存在，而對於一個高級的IM系統，會採用讀寫擴散混合的同步模式，來滿足這類產品的需求。採用混合模式，會根據數據的不同類型和不同的讀寫負載，來決定用寫擴散還是讀擴散。

典型架構設計

如圖是一個典型的消息系統架構，架構中包含幾個重要組件：

• 端

  ：作為消息的發送和接收端，通過連接消息伺服器來發送和接收消息。

• 消息伺服器

  ：一組無狀態的伺服器，可水平擴展，處理消息的發送和接收請求，連接後端消息系統。

• 消息隊列

  ：新寫入消息的緩衝隊列，消息系統的前置消息存儲，用於削峰填谷以及非同步消費。

• 消息處理

  ：一組無狀態的消費處理伺服器，用於非同步消費消息隊列中的消息數據，處理消息的持久化和寫擴散同步。

• 消息存儲和索引庫

  ：持久化存儲消息，每個會話對應一個Timeline進行消息存儲，存儲的消息建立索引來實現消息檢索。

• 消息同步庫

  ：寫擴散形式同步消息，每個用戶的收件箱對應一個Timeline，同步庫內消息不需要永久保存，通常對消息設定一個生命周期。

• 新消息會由端發出，通常消息體中會攜帶消息ID（用於去重）、邏輯時間戳（用於排序）、消息類型（控制消息、圖片消息或者文本消息等）、消息體等內容。消息會先寫入消息隊列，作為底層存儲的一個臨時緩衝區。消息隊列中的消息會由消息處理伺服器消費，可以允許亂序消費。消息處理伺服器對消息先存儲後同步，先寫入發件箱Timeline（存儲庫），後寫擴散至各個接收端的收件箱（同步庫）。消息數據寫入存儲庫後，會被近實時的構建索引，索引包括文本消息的全文索引以及多欄位索引（發送方、消息類型等）。

對於在線的設備，可以由消息伺服器主動推送至在線設備端。對於離線設備，登錄後會主動向服務端同步消息。每個設備會在本地保留有最新一條消息的順序ID，向服務端同步該順序ID後的所有消息。

總結

本篇文章主要介紹了現代IM系統中消息系統所需要具備的能力，對比了傳統架構和現代架構。為方便接下來的深入探討，介紹了表格存儲Tablestore推出的Timeline模型，以及在IM系統中消息存儲和消息同步模型的基本概念和策略，最後介紹了一個典型的架構設計。

作者：木洛

原文鏈接?：https://my.oschina.net/yunqi/blog/3037537

本文為雲棲社區原創內容，未經允許不得轉載。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！