简介：序消息类场景是表格存储（Tablestore）主推的方向之一，因其数据存储结构在消息类数据存储上具有天然优势。为了方便用户基于Tablestore为消息类场景建模，Tablestore封装Timeline模型，旨在让用户更快捷的实现消息类场景需求。
序
消息类场景是表格存储（Tablestore）主推的方向之一，因其数据存储结构在消息类数据存储上具有天然优势。为了方便用户基于Tablestore为消息类场景建模，Tablestore封装Timeline模型，旨在让用户更快捷的实现消息类场景需求。在推出Timeline（v1、v2两个版本）模型以来，受到了大量用户关注。伴随模型推广与输出，Tablestore陆续发布了一系列专题文章，重点讨论介绍了IM场景的架构设计、模型概念以及Feed 流系统架构的设计方案，相信给很多用户提供了场景实现新思路。文章列表见《表格存储权威指南》。
但依然会有用户困惑，“框架、结构、模型等概念介绍了这么多，该如何基于Timeline模型，实现具体场景呢？”。
本文就是为了让用户更快速的上手，带用户基于Timeline2.0 模型，详细讲解如何实现一个简易的IM系统。并开源了相应的实现代码。源码链接
相关系列文章见：《现代IM系统中的消息系统架构 - 架构篇》、《现代IM系统中的消息系统架构 - 模型篇》
梗概
生活中最常见的即时聊天类软件如：钉钉、微信等，都可以描述为：实现了即时通讯能力的聊天工具。其中聊天会话可分为两大类，分别是：单聊、群聊（公众号类似单聊）。这里我们以钉钉（Ding Talk）的功能为参照，详细说明相应的功能基于Tablestore的Timeline模型如何实现。如：新消息提醒，未读消息数统计，查看会话中更久的聊天内容，群名模糊检索，关键字查询历史记录，以及多客户端同步等。让用户在实现方案上有更清晰的认识，对模型的抽象概念、接口有更好的理解。
下面会按照聊天系统的功能模块分段，分别介绍每一部分的功能、方案介绍、表设计以及实现代码等。功能模块主要分为：消息存储、关系维护、即时感知、多端同步。
功能模块
消息存储
消息系统中，消息存储是最基本的功能。对于消息存储（提供消息的读、写、持久化），一方面需要持久化写入，保证消息数据的不丢失，另一方面，适合用户的快速、高效查询。在IM场景中，写入方式通常是单行、批量写入，而读取需要按照消息队列范围读取。有时用户还有对于历史消息的模糊查询需求，这时就需要使用多维检索、全文检索的能力。
消息的存储都是基于Timeline模型，具体模型见文章《Tablestore发布Timeline 2.0模型》。样例中，消息数据的表结构见下图：
表设计：im_timeline_store_table
存储库
功能：会话窗口消息展示
存储库是聊天会话消息所对应的存储表，消息以会话分类存储，每个会话是一个消息队列。单个消息队列（TimelineQueue）通过timelineId唯一标识，所有消息基于sequenceId有序排列。消息体中含有发送人、消息id（消息去重）、消息发送时间、消息体内容、消息类型（类型包含图片、文件、普通文本，本文仅适用文本）等。
图片来自公开交流群截图
如上图，当用户点击某一个会话时，窗口会展示相应会话的最新一页消息。图片里的消息都是从存储库拉取的，通过timelineId获取该会话的Queue实例，然后调用Queue的scan接口与ScanParam参数（sequenceId范围+倒序）拉取最新的一页消息。当用户向上滚动，展示完这一页消息后，客户端会基于第一次请求的最小sequencId发起第二次请求，获取第二页消息记录，单页消息数通常选择20-30条。会话的消息可以选择在客户端持久化，然后在感知到新消息之后更新本地消息，增加缓存减少网络IO。
核心代码
public List
TimelineStore store = timelineV2.getTimelineStoreTableInstance();
TimelineIdentifier identifier = new TimelineIdentifier.Builder()
.addField("timeline_id", timelineId)
.build();
ScanParameter parameter = new ScanParameter()
.scanBackward(sequenceId)
.maxCount(30);
Iterator
List
while (iterator.hasNext() && counter++ <= 30) {
TimelineEntry timelineEntry = iterator.next();
AppMessage appMessage = new AppMessage(timelineId, timelineEntry);
appMessages.add(appMessage);
}
return appMessages;
}
存储库的消息需要永久保存，是整个应用的全量消息存储。存储库数据过期时间（TTL）需要设为-1。
功能：多维组合、全文检索
全文检索能力就是对存储库的消息内容做模糊查询，因而需要对存储库的数据建立多元索引。具体索引字段，需要根据设计需求设计。如钉钉公开群的检索，需要对群ID、消息发送人、消息类型、消息内容、以及时间建立索引，其中消息内容需要使用分词字符串类型，从而提供模糊查询的能力。
核心代码
public List
TimelineStore store = timelineV2.getTimelineStoreTableInstance();
TimelineIdentifier identifier = new TimelineIdentifier.Builder()
.addField("timeline_id", timelineId)
.build();
ScanParameter parameter = new ScanParameter()
.scanBackward(sequenceId)
.maxCount(30);
Iterator
List
int counter = 0;
while (iterator.hasNext() && counter++ <= 30) {
TimelineEntry timelineEntry = iterator.next();
AppMessage appMessage = new AppMessage(timelineId, timelineEntry);
appMessages.add(appMessage);
}
return appMessages;
}
另外，为了做消息的权限管理，仅允许用户检索自己有权限查看的消息，可在消息体字段中扩展接收人ID数组，这样对所有群做检索时，需要增加接收人字段为自己的用户ID这一必要条件，即可实现消息内容的权限限制。 样例中没有实现这一功能，用户可根据需求自己增加、修改。
同步库
功能：新消息即时统计
当客户端在线时，应用的系统服务会维护客户端的长连接，因而可以感知客户端在线。当用户的同步库有新消息写入时（即有新消息），应用会发出信号通知客户端有新消息，然后客户端会基于同步库checkpoint点，拉取同步库中该sequenceId之后的所有新消息，统计各会话的新消息数，并更新checkpoint点。
如上图，对于一个在线客户端，每个会话都会维护一个未读消息的计数（小红点），也会有一个总未读数的计数，这个数量一般会存储在客户端本地，或者通过redis持久化。这些未读消息，指的就是通过同步库拉取并统计过，但是还未被用户点开的消息数量。在拉取到新消息列表后，客户端（或应用层）会遍历所有新消息，然后将新消息所对应会话的未读计数累加1，这样实现了未读消息的即时感知与更新。只有当用户点开会话后，会话的未读计数才会清零。
在更新未读数的同时，会话列表中还会有最新消息的简短摘要信息以及最新消息的发送时间等。这些可以在遍历新消息列表时不断更新。这些统计、摘要都是依托同步库，而非存储库实现的。
核心代码
public List
TimelineStore sync = timelineV2.getTimelineSyncTableInstance();
TimelineIdentifier identifier = new TimelineIdentifier.Builder()
.addField("timeline_id", userId)
.build();
ScanParameter parameter = new ScanParameter()
.scanForward(lastSequenceId)
.maxCount(30);
Iterator
List
int counter = 0;
while (iterator.hasNext() && counter++ <= 30) {
AppMessage appMessage = new AppMessage(userId, iterator.next());
appMessages.add(appMessage);
}
return appMessages;
}
在统计到会话列表中不存在的会话时，客户端会做一次额外请求。通过timelineID获取会话的基本描述信息，如群头像或好友的头像、群名称等，并初始化未读数计时器0，然后累加新消息数、更新最新消息摘要等。
同步库对于IM场景下的新消息即时感知统计这一核心功能，就是通过写入冗余的方式，提升新消息读取统计的效率与速度。对于IM场景没有收件箱的概念，因而同步库中冗余消息并没有永久保存的价值，提供7天过期时间已经足够保证功能正常。用户可以根据自身需求，调整同步库的数据过期时间（TTL）。
功能：异步写扩散
在本文的样例中，单聊会话的消息在写完存储库后同时写入了同步库，只有两行的写入开销很小。但是对于群会话，写完存储库后要获取群用户列表，然后依次写入相应用户的同步库。这种方式在群少、用户少时不会有问题，但随着用户体量、活跃度的增加，同步的写的方式就会面临性能问题，因此建议用户对群写扩散使用异步任务实现。
用户可以基于表格存储实现一个任务队列，将写扩散任务写入队列中后直接返回，然后由其他进程保证任务队列的执行。任务队列保存了群ID、消息的完整信息，消费进程不断轮询读取新任务，获取任务后，才会从群关系表中获取完整的群成员列表，并做相应的写扩散。
任务队列可以直接基于Tablestore实现，表设计为两列主键，第一列为topic，第二列为自增列，一个topic对应一个队列，任务会被有序写入单个队列中。当并发量持续膨胀后，可对任务做hash分桶，随机写入多个topic。这样可以增加消费者数量（消费并发量），提升写扩散效率。对应任务队列消费，用户只需要维护每个topic的checkpoint点。checkpoint点之前的为已完成任务，通过getRange的方式顺序获取checkpoint点之后未执行的新任务，保证任务的执行。失败的任务可以重新写入任务队列来提升容错，并增加重试计数。出现多次失败后放弃重写，然后将该任务写入特殊的问题队列，方便应用的开发者们查询、定位问题。
元数据管理
所谓元数据，就是描述数据的数据。在这里主要体现为两类：用户元数据、会话元数据。这里群的元数据信息：群ID（复用群的timelineId）、群名称、创建时间等信息，可以直接基于timelineMeta的管理表完成实现，所有Group类型的TimelineMeta可以映射为一个Group。但是用户的元数据却不能复用TimelineMeta，所以需要单独的表实现。
用户元数据
即用户的属性信息，通过用户ID识别特定用户。在上面提到的用户关系中，通过用户的标识ID确认用户身份，但用户的属性信息，如：性别、签名、头像等信息，还是需要单独维护。因此需要单独维护。
表设计：im_user_table
用户元数据以user_id为标识，与同步库中的timeline_id一一对应。用户同步新消息时，只会拉取同步库中自己对应的单个消息队列（TimelineQueue）。因此，为了唯一ID的方便管理，我们可以选择user_id与用户同步库的timeline_id使用同一个值。这样一来，在消息写扩散时，只需知道群内用户的user_id列表回好友user_id，即可以完成写扩算。
功能：用户检索
对于用户，添加好友的需求有很多种，这里我们只需要维护用户表，并且创建多元索引，即可轻松实现。样例中没有实现，用户可以根据自己需求配置不同的索引字段设置，这里我们仅简单分析一下需求：
通过用户ID：主键查询；
二维码（含用户ID信息）：主键查询；
用户姓名：多元索引，用户名字段设置分词字符串；
用户标签：多元索引，数组字符串索引提供签检索、嵌套索引提供多标签打分检索排序；
附近的人：多元索引，GEO索引查询附近、特定地理围栏的人；
详细的多元索引功能，用户可参看官网文档：多元索引
会话元数据
即会话的属性信息，通过唯一会话ID识别特定会话，属性信息会包含：会话类别（群、单聊、公众号等）、群名称、公告、创建时间等。同时，通过群名称模糊查找群，也会是会话元数需要的重要能力。
在Timeline模型中，提供了Timeline Meta的管理能力，只需通过相应的接口便可实现会话meta的管理。
存储库中管理的是会话的消息队列（TimelineQueue），这里与会话元数据中的行一一对应。客户端用户选中特定会话后，应用从相应的消息队列倒序批量拉取消息展示到客户端，群聊单聊的使用方式一样，因而并不做会话类型的区分。
功能：群检索
用户如果有加入群的需求，首先需要查询到特定的群。查询群的方式与用户查询方式类似，功能也可以做相同的实现。用户可以根据自己需求定制不同的索引字段设置，需求实现方式如下：
群ID：主键查询；
二维码（含用户ID信息）：主键查询；
群名：多元索引，用户名字段设置分词字符串；
群标签：多元索引，数组字符串索引提供签检索、嵌套索引提供多标签打分检索排序；
注：会话元数据可以直接维护单聊会话与人的映射关系。对于单聊的meta增加一列users字段，存放两个用户ID，这样不用额外维护关系表（基于单聊关系表im_user_relation_table创建timeline_id为第一列主键的二级索引）。
欢迎加入“表格存储公开交流群”。表格存储 (Tablestore) 提供专业的免费的技术咨询服务，期待为您服务。群号 : 11789671
想看完整文章内容：点击这里
原文出处：阿里云大学开发者社区