现代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系统，敬请期待。