現代IM系統中的消息系統架構 - 模型篇

前言

在架構篇中咱們介紹了現代IM消息系統的架構，介紹了Timeline的抽象模型以及基於Timeline模型構建的一個支持『消息漫遊』、『多端同步』和『消息檢索』多種高級功能的消息系統的典型架構。架構篇中爲了簡化讀者對Tablestore Timeline模型的理解，概要性的對Timeline的基本邏輯模型作了介紹，以及對消息系統中消息的多種同步模式、存儲和索引的基本概念作了一個科普。

本篇文章是對架構篇的一個補充，會對Tablestore的Timeline模型作一個很是詳盡的解讀，讓讀者可以深刻到實現層面瞭解Timeline的基本功能以及核心組件。最後咱們仍是會基於IM消息系統這個場景，來看如何基於Tablestore Timeline實現IM場景下消息同步、存儲和索引等基本功能。

Timeline模型

Timeline模型以『簡單』爲設計目標，核心模塊構成比較清晰明瞭，主要包括：

• Store：Timeline存儲庫，相似數據庫的表的概念。
• Identifier：用於區分Timeline的惟一標識。
• Meta：用於描述Timeline的元數據，元數據描述採用free-schema結構，可自由包含任意列。
• Queue：一個Timeline內全部Message存儲在Queue內。
• Message：Timeline內傳遞的消息體，也是一個free-schema的結構，可自由包含任意列。
• Index：包含Meta Index和Message Index，可對Meta或Message內的任意列自定義索引，提供靈活的多條件組合查詢和搜索。

Timeline Store

Timeline Store是Timeline的存儲庫，對應於數據庫內表的概念。上圖是Timeline Store的結構圖，Store內會存儲全部的Timeline數據。Timeline是一個面向海量消息的數據模型，同時用於消息存儲庫和同步庫，須要知足多種要求：

• 支撐海量數據存儲：對於消息存儲庫來講，若是須要消息永久存儲，則隨着時間的積累，數據規模會愈來愈大，須要存儲庫能應對長時間積累的海量消息數據存儲，須要能達到PB級容量。
• 低存儲成本：消息數據的冷熱區分是很明顯的，大部分查詢都會集中在熱數據，因此對於冷數據須要有一個比較低成本的存儲方式，不然隨着時間的積累數據量不斷膨脹，存儲成本會很是大。
• 數據生命週期管理：不論是對於消息數據的存儲仍是同步，數據都須要定義生命週期。存儲庫是用於在線存儲消息數據自己，一般須要設定一個較長週期的保存時間。而同步庫是用於寫擴散模式的在線或離線推送，一般設定一個較短的保存時間。
• 極高的寫入吞吐：各種場景下的消息系統，除了相似微博、頭條這種類型的Feeds流系統，像絕大部分即時通信或朋友圈這類消息場景，一般是採用寫擴散的消息同步模式，寫擴散要求底層存儲具有極高的寫入吞吐能力，以應對消息洪峯。
• 低延遲的讀：消息系統一般是應用在在線場景，因此對於查詢要求低延遲。

Tablestore Timeline的底層是基於LSM存儲引擎的分佈式數據庫，LSM的最大優點就是對寫入很是友好，自然適合消息寫擴散的模式。同時對查詢也作了極大優化，例如熱數據進緩存、bloom filter等等。數據表採用Range Partition的分區模式，能提供水平擴展的服務能力，以及能自動探測並處理熱點分區的負載均衡策略。爲了知足同步庫和存儲庫對存儲的不一樣要求，也提供了一些靈活的自定義配置，主要包括：

• Time to live（數據生命週期）：可自定義數據生命週期，例如永久保存，或者保存N天。
• Storage type（存儲類型）：自定義存儲類型，對存儲庫來講，HDD是最好的選擇，對同步庫來講，SSD是最好的選擇。

Timeline Module

Timeline Store內能存儲海量的Timeline，單個Timeline的詳細結構圖如上，能夠看到Timeline主要包含了三大部分：

• Timeline Meta：元數據部分，用於描述Timeline，包括：

• • Identifier：用於惟一標識Timeline，可包含多個字段。
  • Meta：用於描述Timeline的元數據，可包含任意個數任意類型的字段。
  • Meta Index：元數據索引，可對元數據內任意屬性列建索引，支持多字段條件組合查詢和檢索。

• Timeline Queue：用於存儲和同步消息的隊列，隊列中元素由兩部分組成：

• • Sequence Id：順序ID，隊列中用於定位Message的位點信息，在隊列中順序ID保持遞增。
  • Message：隊列中承載消息的實體，包含了消息的完整內容。

• Timeline Data：Timeline的數據部分就是Message，Message主要包含：

• • Message：消息實體，其內部也能夠包含任意數量任意類型字段。
  • Message Index：消息數據索引，可對消息實體內任意列作索引，支持多字段條件組合查詢和檢索。

IM消息系統建模

以一個簡易版IM系統爲例，來看如何基於Tablestore Timeline模型建模。按照上圖中的例子，存在A、B、C三個用戶，A與B發生單聊，A與C發生單聊，以及A、B、C組成一個羣聊，來看下在這個場景下消息同步、存儲以及讀寫流程分別如何基於Tablestore Timeline建模。

消息同步模型

消息同步選擇寫擴散模型，能徹底利用Tablestore Timeline的優點，以及針對IM消息場景讀多寫少的特性，經過寫擴散來平衡讀寫，均衡整個系統的資源。寫擴散模型下，每一個接收消息的個體均擁有一個收件箱，全部須要同步至該個體的消息須要投遞到其收件箱內。圖上例子中，A、B、C三個用戶分別擁有收件箱，每一個用戶不一樣的設備端，均從同一個收件箱內拉取新消息。

消息同步庫

收件箱存儲在同步庫內，同步庫中每一個收件箱對應一個Timeline。根據圖上的例子，總共存在3個Timeline做爲收件箱。每一個消息接收端保存有本地最新拉取的消息的SequenceID，每次拉取新消息均是從該SequenceID開始拉取消息。對同步庫的查詢會比較頻繁，一般是對最新消息的查詢，因此要求熱數據儘可能緩存在內存中，能提供高併發低延遲的查詢。因此對同步庫的配置，通常是須要SSD存儲。消息若是已經同步到了全部的終端，則表明收件箱內的該消息已經被消費完畢，理論上能夠清理。但設計上來講不作主動清理，而是給數據定義一個較短的生命週期來自動過時，通常定義爲一週或者兩週。數據過時以後，若是仍要同步拉取新消息，則須要退化到讀擴散的模式，從存儲庫中拉取消息。

消息存儲庫

消息存儲庫中保存有每一個會話的消息，每一個會話的發件箱對應一個Timeline。發件箱內的消息支持按會話維度拉取消息，例如瀏覽某個會話內的歷史消息則經過讀取發件箱完成。通常來講，新消息經過在線推送或者查詢同步庫可投遞到各個接收端，因此對存儲庫的查詢會相對來講較少。而存儲庫用於長期存儲消息，例如永久存儲，相對同步庫來講數據量會較大。因此存儲庫的選擇通常是HDD，數據生命週期根據消息須要保存的時間來定，一般是一個較長的時間。

消息索引庫

消息索引庫依附於存儲庫，使用了Timeline的Message Index，能夠對存儲庫內的消息進行索引，例如對文本內容的全文索引、收件人、發件人以及發送時間的索引等，能支持全文檢索等高級查詢和搜索。

總結

本篇文章主要對Tablestore Timeline模型進行了詳解，介紹了Timeline各模塊包括Store、Meta、Queue、Data和Index等，最後以一個簡單的IM場景舉例如何基於Timeline來建模。在下一篇實現篇中，會直接基於Tablestore Timeline來實現一個簡易版的支持單聊、羣聊、元數據管理以及消息檢索的IM系統，敬請期待。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。