文章链接
其实自己直接点开来一个一个的食用也是挺不错的
学习归纳
消息系统中最核心的功能是消息的同步和存储
消息的同步
将消息完整的、快速的从发送方传递到接收方。
衡量指标：消息传递的实时性、完整性以及消息规模
对应功能：在线/离线消息推送，多端同步
消息的存储
消息的持久化保存
对应功能：消息漫游
同时，消息的检索也是消息系统中很重要的一大功能，它使得消息具备在线全文检索的能力
消息系统架构图
消息是先存储后同步，确保接收方接收的到消息的时候，消息已经在云端保存了
同时，消息会由消息存储库、消息同步库两个库来保存
消息存储库用于全量保存所有会话的消息
消息同步库用于接收方的多端同步
- 消息从发送方发出后，经过服务端转发。服务端会先将消息保存到消息存储库，后保存到消息同步库（图中步骤1、2）
- 在完成持久化保存后，对于在线的接收方直接推送（步骤3、4）。对于推送失败或离线的接收方，由另外一个统一的消息同步方式。接收方主动向服务端拉取所有未同步消息
接收方何时来同步以及会在哪些端来同步消息对服务端来说是未知的，所以要求服务端必须保存所有需要同步到接收方的消息，这是消息同步库保存消息的主要作用
- 对于新的同步设备（客户端），会有消息漫游的需求（步骤5），这是消息存储库的主要作用。在消息存储库中，可以拉取任意会话的全量历史消息。
- 消息检索的实现依赖于对消息存储库内消息的索引，通常是一个近实时（NRT，near real time）的索引构建过程
基础模型
网上很多消息系统的实现，实现差异主要体现在消息同步和存储的方案上，在消息的数据模型上其实有很大的共性。围绕数据同步模型的讨论主要在『读扩散』、『写扩散』和『混合模式』这三种方案
timeline是基于表格存储Tablestore提出的消息模型，是对系统内消息模型的抽象
Timeline模型
Timeline是一个对消息抽象的逻辑模型，后续的消息同步库和存储库的设计和实现也是围绕Timeline的特性和需求来展开。
Timeline可以简单理解为是一个消息队列，但这个消息队列有如下特性：
- 每条消息对应一个顺序ID：每个消息拥有一个唯一的顺序ID（SequenceId），队列消息按SequenceId排序。
- 新消息写入能自动分配递增的顺序ID，保证永远插入队尾，timeline中根据顺序id来确定同步消息的同步位点
- 新消息写入也能自定义顺序ID，满足自定义排序需求：上面一点主要是为了满足同步的需要，而消息的存储，通常要求能根据会话顺序来排序，会话顺序一般由端决定，而不是服务端的同步顺序（其实不是很明白这点，类似于置顶会话，为什么要用顺序ID来做）
- 支持根据顺序ID的随机定位：根据SequenceId随机定位到Timeline中的某个位置，从这个位置开始正序或逆序的读取消息，或就读取那条消息
- 支持对消息的自定义索引
消息同步可以基于Timeline很简单的实现，上图的例子中，消息发送方是A，消息接收方是B，同时B存在多个接收端，分别是B1、B2和B3。
A向B发送消息，消息需要同步到B的多个端，待同步的消息通过一个Timeline来进行交换。A向B发送的所有消息，都会保存在这个Timeline中，B的每个接收端都是独立的从这个Timeline中拉取消息。
每个接收端同步完毕后，都会在本地记录下最新同步到的消息的SequenceId，即最新的一个位点，作为下次消息同步的起始位点。服务端不会保存各个端的同步状态，各个端均可以在任意时间从任意点开始拉取消息。
消息存储也是基于Timeline实现，和消息同步唯一的区别是，消息存储要求服务端能够对Timeline内的所有数据进行持久化，并且消息采用会话顺序来保存，需要自定义顺序ID。
消息存储模型
消息存储要求每个会话都对应一个独立的Timeline。如图例子所示，A与B/C/D/E/F均发生了会话，每个会话对应一个独立的Timeline，每个Timeline内存有这个会话中的所有消息，消息根据会话顺序排序，服务端会对每个Timeline进行持久化存储，也就拥有了消息漫游的能力。
消息同步模型
消息的同步一般有读扩散（也叫拉模式）和写扩散（也叫推模式）两种不同的方式，分别对应不同的Timeline物理模型。
题外话，纠结写扩散读扩散的定义是为了更好的就概念达成统一的认识。词汇概念的定义本身没什么意义，为词汇定义统一的概念认知有助于高效沟通
读扩散：每个会话的Timeline中保存了这个会话的全量消息。读扩散的消息同步模式下，每个会话中产生的新的消息，只需要写一次到其用于存储的Timeline中，接收端从每个Timeline中拉取新的消息。消息只需要写一次，相比写扩散的模式，能够大大降低消息写入次数，但接收端去同步消息的逻辑会相对复杂和低效。
写扩散：写扩散的消息同步模式，有一个额外的Timeline来专门用于消息同步，通常是每个接收端都会拥有一个独立的同步Timeline（或者叫收件箱），用于存放需要向这个接收端同步的所有消息。写扩散同步模式的优点是，接收端的消息同步逻辑非常简单，只需要从其同步Timeline中读取一次即可。
在它的设计中，读扩散只是将消息写入消息存储的timeline。而写扩散还需要写入到需要同步的接收端的同步timeline
写扩散下在A对B会话中，消息会额外写两次，消息需要写入参与这个会话的两个接收者A和B的同步Timeline
针对IM这种应用场景，消息系统通常会选择写扩散这种消息同步模式。IM场景下，一条消息只会产生一次，但是会被读取多次，是典型的读多写少的场景。
典型架构设计
消息队列：消息系统的前置消息存储，用于削峰填谷以及异步消费。
消息处理：一组无状态的消费处理服务器，用于异步消费消息队列中的消息数据，处理消息的持久化和写扩散同步。
消息存储和索引库：持久化存储消息，每个会话对应一个Timeline进行消息存储
消息同步库：仅写扩散同步消息使用，每个用户的收件箱对应一个Timeline
Timeline模型详解
这部分将介绍Tablesotre中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内的任意列自定义索引，提供灵活的多条件组合查询和搜索。
下面为Tablestore 的Timeline Store
Timeline Store是Timeline的存储库，阿里的Tablestore底层是基于LSM存储引擎的分布式数据库（LSM树牺牲了部分读性能来大幅提高写性能）
Timeline Module
Timeline Store内能存储海量的Timeline，单个Timeline的详细结构图如上，可以看到Timeline主要包含了三大部分：
- Timeline Meta：元数据部分
- Timeline Queue：队列部分，用于存储和同步消息的队列
- Timeline Data：数据部分，就是Message
元数据部分用于描述Timeline，包括：
- Identifire：唯一标识Timeline，可包含多个字段
- Meta：用于描述Timeline的元数据
- Meta Index：元数据索引，对元数据内任意属性列建索引
队列部分中元素由两部分组成：
- Sequence Id：顺序ID，定位消息的位点信息
- Message：队列中承载消息的实体
数据部分，一个Message Body主要包含：
- Message：消息实体
- Message Index：对消息实体内任意列做索引
IM消息系统建模
以一个简易版IM系统为例，来看如何基于Tablestore Timeline模型建模。
按照上图中的例子，存在A、B、C三个用户，A与B发生单聊，A与C发生单聊，以及A、B、C组成一个群聊，来看下在这个场景下消息同步、存储以及读写流程分别如何基于Tablestore Timeline建模。
这里的IM消息系统建模是使用写扩散的混合模式，可以发现 群聊会话没有在同步库中
写扩散模型下，每个接收消息的个体均拥有一个收件箱，所有需要同步至该个体的消息需要投递到其收件箱内。图上例子中，A、B、C三个用户分别拥有收件箱，每个用户不同的设备端，均从同一个收件箱内拉取新消息。
消息同步库
收件箱存储在同步库内，同步库中每个收件箱对应一个Timeline。对同步库的查询会比较频繁，通常是对最新消息的查询，所以要求热数据尽量缓存在内存中，能提供高并发低延迟的查询。所以对同步库的配置，一般是需要SSD存储。
消息存储库
消息存储库中保存有每个会话的消息，每个会话的发件箱对应一个Timeline。
发件箱内的消息支持按会话维度拉取消息，例如浏览某个会话内的历史消息则通过读取发件箱完成。一般来说，新消息通过在线推送或者查询同步库可投递到各个接收端，所以对存储库的查询会相对来说较少。而存储库用于长期存储消息，例如永久存储，相对同步库来说数据量会较大。所以存储库的选择一般是HDD。
消息索引库
消息索引库依附于存储库，使用了Timeline的Message Index，可以对存储库内的消息进行索引，例如对文本内容的全文索引、收件人、发件人以及发送时间的索引等，能支持全文检索等高级查询和搜索。
最后一篇文章就是基于Tablestore Timeline来实现一个简易版的支持单聊、群聊、元数据管理以及消息检索的IM系统
