现代IM系统中消息推送和存储架构的实现

摘要：前言 IM全称是『Instant Messaging』，中文名是即时通信。在这个高度信息化的移动互联网时代，生活中IM类产品已经成为必备品，比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。固然目前微信已经成长为一个生态型产品，但其核心功能仍是IM。

前言

IM全称是『Instant Messaging』，中文名是即时通信。在这个高度信息化的移动互联网时代，生活中IM类产品已经成为必备品，比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。固然目前微信已经成长为一个生态型产品，但其核心功能仍是IM。还有一些非以IM系统为核心的应用，最典型的如一些在线游戏、社交应用，IM也是其重要的功能模块。能够说，带有社交属性的应用，IM功能必定是必不可少的。

IM系统在互联网初期即存在，其基础技术架构在这十几年的发展中更新迭代屡次，从早期的CS、P2P架构，到如今后台已经演变为一个复杂的分布式系统，涉及移动端、网络、安全和存储等技术的方方面面。其支撑的规模也从早期的少许日活，到如今微信这个巨头最新公布的达到9亿的日活的体量。

IM系统中最核心的部分是消息系统，消息系统中最核心的功能是消息的同步和存储：

消息的同步：将消息完整的、快速的从发送方传递到接收方，就是消息的同步。消息同步系统最重要的衡量指标就是消息传递的实时性、完整性以及能支撑的消息规模。从功能上来讲，通常至少要支持在线和离线推送，高级的IM系统还支持『多端同步』。

消息的存储：消息存储即消息的持久化保存，这里不是指消息在客户端本地的保存，而是指云端的保存，功能上对应的就是『消息漫游』。『消息漫游』的好处是能够实现帐号在任意端登录查看全部历史消息，这也是高级IM系统特有的功能之一。

本篇文章内容主要涉及IM系统中的消息系统架构，会介绍一种基于TableStore构建的消息同步以及存储系统的架构实现，可以支持消息系统中的高级特性『多端同步』以及『消息漫游』。在性能和规模上，可以作到全量消息云端存储，百万TPS以及毫秒级延迟的消息同步能力。

架构设计

本章主要会介绍基于TableStore的现代IM消息系统的架构设计，在详细介绍架构设计以前，会先介绍一种Timeline逻辑模型，来抽象和简化对IM消息同步和存储模型的理解。理解了Timeline模型后，会介绍如何基于此模型对消息的同步以及存储进行建模。基于Timeline模型，在实现消息同步和存储时还会有各方面的技术权衡，例如如何对消息同步常见的读扩散和写扩散两种模型进行对比和选择，以及针对Timeline模型的特征如何来选择底层数据库。

传统架构 vs 现代架构

上图是消息系统传统架构与现代架构的简单对比。

传统架构下，消息是先同步后存储。对于在线的用户，消息会直接实时同步到在线的接收方，消息同步成功后，并不会进行持久化。而对于离线的用户或者消息没法实时同步成功时，消息会持久化到离线库，当接收方从新链接后，会从离线库拉取全部未读消息。当离线库中的消息成功同步到接收方后，消息会从离线库中删除。传统的消息系统，服务端的主要工做是维护发送方和接收方的链接状态，并提供在线消息同步和离线消息缓存的能力，保证消息必定可以从发送方传递到接收方。服务端不会对消息进行持久化，因此也没法支持消息漫游。

现代架构下，消息是先存储后同步。先存储后同步的好处是，若是接收方确认接收到了消息，那这条消息必定是已经在云端保存了。而且消息会有两个库来保存，一个是消息存储库，用于全量保存全部会话的消息，主要用于支持消息漫游。另外一个是消息同步库，主要用于接收方的多端同步。消息从发送方发出后，通过服务端转发，服务端会先将消息保存到消息存储库，后保存到消息同步库。完成消息的持久化保存后，对于在线的接收方，会直接选择在线推送。但在线推送并非一个必须路径，只是一个更优的消息传递路径。对于在线推送失败或者离线的接收方，会有另一个统一的消息同步方式。接收方会主动的向服务端拉取全部未同步消息，但接收方什么时候来同步以及会在哪些端来同步消息对服务端来讲是未知的，因此要求服务端必须保存全部须要同步到接收方的消息，这是消息同步库的主要做用。对于新的同步设备，会有消息漫游的需求，这是消息存储库的主要做用，在消息存储库中，能够拉取任意会话的全量历史消息。

以上是传统架构和现代架构的一个简单的对比，现代架构上整个消息的同步和存储流程，并无变复杂太多，可是其能实现多端同步以及消息漫游。现代架构中最核心的就是两个消息库『消息同步库』和『消息存储库』，是消息同步和存储最核心的基础。而本篇文章接下来的部分，都是围绕这两个库的设计和实现来展开。

Timeline模型

在分析『消息同步库』和『消息存储库』的设计和实现以前，在本章会先介绍一个逻辑模型-Timeline。Timeline模型会帮助咱们简化对消息同步和存储模型的理解，而消息库的设计和实现也是围绕Timeline的特性和需求来展开。

如图是Timeline模型的一个抽象表述，Timeline能够简单理解为是一个消息队列，但这个消息队列有以下特性：

每一个消息拥有一个顺序ID（SeqId），在队列后面的消息的SeqId必定比前面的消息的SeqId大，也就是保证SeqId必定是增加的，可是不要求严格递增。

新的消息永远在尾部添加，保证新的消息的SeqId永远比已经存在队列中的消息都大。

可根据SeqId随机定位到具体的某条消息进行读取，也能够任意读取某个给定范围内的全部消息。

有了这些特性后，消息的同步能够拿Timeline来很简单的实现。图中的例子中，消息发送方是A，消息接收方是B，同时B存在多个接收端，分别是B一、B2和B3。A向B发送消息，消息须要同步到B的多个端，待同步的消息经过一个Timeline来进行交换。A向B发送的全部消息，都会保存在这个Timeline中，B的每一个接收端都是独立的从这个Timeline中拉取消息。每一个接收端同步完毕后，都会在本地记录下最新同步到的消息的SeqId，即最新的一个位点，做为下次消息同步的起始位点。服务端不会保存各个端的同步状态，各个端都可以在任意时间从任意点开始拉取消息。

消息漫游也是基于Timeline，和消息同步惟一的区别是，消息漫游要求服务端可以对Timeline内的全部数据进行持久化。

基于Timeline，从逻辑模型上可以很简单的理解在服务端如何去实现消息同步和存储，并支持多端同步和消息漫游这些高级功能。落地到实现的难点主要在如何将逻辑模型映射到物理模型，Timeline的实现对数据库会有哪些要求？咱们应该选择何种数据库去实现？这些是接下来会讨论到的问题。

消息存储模型

如图是基于Timeline的消息存储模型，消息存储要求每一个会话都对应一个独立的Timeline。如图例子所示，A与B/C/D/E/F均发生了会话，每一个会话对应一个独立的Timeline，每一个Timeline内存有这个会话中的全部消息，服务端会对每一个Timeline进行持久化。服务端可以对全部会话Timeline中的全量消息进行持久化，也就拥有了消息漫游的能力。

消息同步模型

消息同步模型会比消息存储模型稍复杂一些，消息的同步通常有读扩散和写扩散两种不一样的方式，分别对应不一样的Timeline物理模型。

如图是读扩散和写扩散两种不一样同步模式下对应的不一样的Timeline模型，按图中的示例，A做为消息接收者，其与B/C/D/E/F发生了会话，每一个会话中的新的消息都须要同步到A的某个端，看下读扩散和写扩散两种模式下消息如何作同步。

读扩散：消息存储模型中，每一个会话的Timeline中保存了这个会话的全量消息。读扩散的消息同步模式下，每一个会话中产生的新的消息，只须要写一次到其用于存储的Timeline中，接收端从这个Timeline中拉取新的消息。优势是消息只须要写一次，相比写扩散的模式，可以大大下降消息写入次数，特别是在群消息这种场景下。但其缺点也比较明显，接收端去同步消息的逻辑会相对复杂和低效。接收端须要对每一个会话都拉取一次才能获取所有消息，读被大大的放大，而且会产生不少无效的读，由于并非每一个会话都会有新消息产生。

写扩散：写扩散的消息同步模式，须要有一个额外的Timeline来专门用于消息同步，一般是每一个接收端都会拥有一个独立的同步Timeline，用于存放须要向这个接收端同步的全部消息。每一个会话中的消息，会产生屡次写，除了写入用于消息存储的会话Timeline，还须要写入须要同步到的接收端的同步Timeline。在我的与我的的会话中，消息会被额外写两次，除了写入这个会话的存储Timeline，还须要写入参与这个会话的两个接收者的同步Timeline。而在群这个场景下，写入会被更加的放大，若是这个群拥有N个参与者，那每条消息都须要额外的写N次。写扩散同步模式的优势是，在接收端消息同步逻辑会很是简单，只须要从其同步Timeline中读取一次便可，大大下降了消息同步所需的读的压力。其缺点就是消息写入会被放大，特别是针对群这种场景。

在IM这种应用场景下，一般会选择写扩散这种消息同步模式。IM场景下，一条消息只会产生一次，可是会被读取屡次，是典型的读多写少的场景，消息的读写比例大概是10:1。若使用读扩散同步模式，整个系统的读写比例会被放大到100:1。一个优化的好的系统，必须从设计上去平衡这种读写压力，避免读或写任意一维触碰到天花板。因此IM系统这类场景下，一般会应用写扩散这种同步模式，来平衡读和写，将100:1的读写比例平衡到30:30。固然写扩散这种同步模式，还须要处理一些极端场景，例如万人大群。针对这种极端写扩散的场景，会退化到使用读扩散。一个简单的IM系统，一般会在产品层面限制这种大群的存在，而对于一个高级的IM系统，会采用读写扩散混合的同步模式，来知足这类产品的需求。

消息库设计

基于Timeline模型，以及Timeline模型在消息存储和消息同步的应用，咱们看下消息同步库和消息存储库的设计。

如图是基于Timeline的消息库设计。

消息同步库：消息同步库用于存储全部用于消息同步的Timeline，每一个Timeline对应一个接收端，主要用做写扩散模式的消息同步。这个库不须要永久保留全部须要同步的消息，由于消息在同步到全部端后其生命周期就能够结束，就能够被回收。可是如前面所介绍的，一个实现简单的多端同步消息系统，在服务端不会保存有全部端的同步状态，而是依赖端本身主动来作同步。因此服务端不知道消息什么时候能够回收，一般的作法是为这个库里的消息设定一个固定的生命周期，例如一周或者一个月，生命周期结束可被淘汰。

消息存储库：消息存储库用于存储全部会话的Timeline，每一个Timeline包含了一个会话中的全部消息。这个库主要用于消息漫游时拉取某个会话的全部历史消息，也用于读扩散模式的消息同步。

消息同步库和消息存储库，对数据库有不一样的要求，如何对数据库作选型，在下面会讨论。

数据库选型

消息系统最核心的两个库是消息同步库和消息存储库，两个库对数据库有不一样的要求：

总结下来，对数据库的要求有以下几点：

1. 表结构设计可以知足Timeline模型的功能要求：不要求关系模型，可以实现队列模型，并可以支持生成自增的SeqId。

2. 可以支持高并发写和范围读，规模在十万级TPS。

3. 可以保存海量数据，百TB级。

4. 可以为数据定义生命周期。

阿里云表格存储（TableStore）是基于LSM存储引擎的分布式NoSQL数据库，支持百万TPS高并发读写，PB级数据存储，数据支持TTL，可以很好的知足以上需求，而且支持自增列，可以很是完美的设计和实现Timeline的物理模型。

架构实现

本章会以一段很是精简的代码，来展现如何基于TableStore实现Timeline模型，并基于Timeline模型进行消息存储和推送。

这篇文章中给出的代码，主要目的是为了演示如何可以实现一个精简Timeline的最基本功能。立刻咱们会推出一个完整的Timeline Library，来将基于Timeline进行消息存储和推送的代码的开发变得无比简单。

全部示例代码基于以下SDK版本：

表结构设计

以上是建立Timeline表的示例代码，总共须要建立两张表，一张表做为消息同步库，名称为『PushTable』，另外一张表做为消息存储库，名称为『StoreTable』。

推送和存储实现

以上是模拟一个群内消息同步和存储的示例代码。群名称为『TableStore(钉钉号：11789671)』，群内成员有『A, B, C, D, E』。群内新的消息，须要先存储到群的存储Timeline（Timeline ID为群名称），以后须要以写扩散的模式推送到群内每一个成员的同步Timeline（以群成员名称做为Timeline ID）。

以上是拉取群内历史消息以及某个群成员进行消息同步的示例代码，主要逻辑在syncMessages函数内。示例代码中，拉取消息都是从seq_id为0开始，0为TableStore自增列中最小值，因此表明了从最小的一个位点开始拉取消息，即拉取全量消息。

后记

这篇文章主要介绍了现代IM系统中消息推送和存储架构的实现，基于逻辑的Timeline模型，咱们能够很清晰明了的理解整个消息推送和存储的架构。基于TableStore，能够很是简单的实现Timeline模型，其中自增列功能，完美的匹配了Timeline模型中所须要的最关键的SeqId自增。

TableStore(表格存储)是阿里云自主研发的专业级分布式NoSQL数据库，是基于共享存储的高性能、低成本、易扩展、全托管的半结构化数据存储平台，支撑互联网和物联网数据的高效计算与分析。IM系统的消息推送和存储场景，是TableStore在社交领域的重要应用之一。

基于Timeline的消息存储和推送模型，将不光应用在IM消息系统中，还可应用在例如Feeds流、实时消息同步、直播弹幕等场景。在Feeds流场景下，咱们也有了比较深刻的研究，能够参考《如何打造千万级Feeds流系统》这篇文章。而在其余更多的场景下，咱们将会有更多的深刻研究。

针对社交场景下对数据的数据高可靠以及服务高可用要求，咱们也一直在建设：

1. 《表格存储如何实现高可靠和高可用》

2. 《表格存储如何实现跨区域的容灾》

同时在新的Serverless架构下，咱们也一直在尝试：

1. 《以物流案例看基于表格存储实时数据流的serverless计算》

除了社交领域，在物联网车联网领域，表格存储也在发挥它强大的分布式数据库能力：

1. 《如何高效存储海量GPS数据》

2. 《超级快递——如何用系统来保证快递准时送达》