消息已读未读的模型设计_阿里云技术专家分享：现代 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 现代架构

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

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

现代架构下，消息是先存储后同步。先存储后同步的好处是，如果接收方确认接收到了消息，那这条消息一定是已经在云端保存了。并且消息会有两个库来保存，一个是消息存储库，用于