关于现代IM系统中聊天消息的同步和存储方案的讨论

来源：即时通讯网 2020-06-29 10:30:49

1，前言

IM的全名是“即时消息”，中文名是即时消息。在这个高度信息化的移动互联网时代，即时通讯产品已成为生活中必不可少的物品，诸如丁鼎，微信，QQ等更著名的产品都将即时通讯作为其核心功能。当然，微信已经成长为生态产品，但其核心功能仍然是即时通讯。也有一些不基于IM系统的应用程序。最典型的是一些在线游戏和社交应用程序。 IM也是重要的功能模块。可以说，对于具有社会属性的应用程序，IM功能必不可少。

IM系统存在于Internet的早期，在十多年的发展中，其基本技术体系结构已多次更新和迭代。从早期的CS和P2P架构开始，背景已经演变成一个复杂的分布式系统。该系统涉及移动终端，网络，安全性和存储技术的各个方面。它的支持范围也从早期的少量日常生活到巨型微信最近宣布的9亿日常生活量。

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

1）消息同步：消息完整且快速从发送者到接收者，消息是同步的。消息同步系统最重要的度量指标是消息传输的实时性，完整性和消息大小。从功能上来看，一般至少支持在线和离线推送，高级IM系统还支持“多端同步”；

2）消息存储：消息存储是消息的持久存储，此处不指客户端上的消息，本地存储是指云存储，对应的功能是“消息漫游”。 “消息漫游”的优点是，您可以在任何一端登录以查看所有历史消息，这也是高级IM系统的独特功能之一。

本文的内容主要涉及IM系统中的消息系统体系结构，并讨论了适合大型用户的消息同步和存储系统体系结构的实现，它可以支持消息系统“多”的高级功能。 -end同步”和“邮件漫游”。在性能和规模方面，它可以实现完整的消息云存储，百万TPS和毫秒级延迟消息同步功能。

2。相关信息

“在IM系统上架构设计”

“谈论移动终端IM上的多点登录和消息漫游的原理”

“如何在移动终端IM登录时通过提取数据来保存数据？ “ [H]“移动终端IM开发的陷阱简介：架构设计，通信协议和客户端”

“一组大量在线用户的移动终端IM架构设计实践共享（包括详细的图形）” [ h]“一套原始的分布式即时消息（IM）系统理论框架解决方案”

“从零到卓越：JD客户服务即时消息系统的技术架构演进过程”

“蘑菇街即时消息/ IM服务器开发架构选择“

”如何确保移动IM中大规模群组消息推送的效率和实时性能？ “ [H]“ IM消息传递保证机制的实现（1）：保证在线实时消息的可靠传递”

“ IM消息传递保证机制的实现（2）：保证离线消息的可靠传递” [

”如何确保IM实时消息的“顺序”和“一致性”？》 [H]《探索一种确保IM消息定时的低成本方法》

>>更多类似文章...

3。架构设计

本章将主要介绍基于TableStore的现代IM消息。在详细介绍架构设计之前，系统的架构设计将首先介绍一个Timeline逻辑模型来抽象和简化对IM的理解。消息同步和存储模型。了解时间轴模型后，我们将介绍如何基于此模型对消息的同步和存储进行建模。基于时间轴模型，在实现消息同步和存储时需要进行各种技术折衷，例如如何比较和选择消息同步的两个常见的读取扩散和写入扩散模型，以及如何为特性选择底层时间轴模型数据库的名称。

讨论现代IM系统中聊天消息的同步和存储方案_1.png

▲上图是消息系统的传统体系结构与现代体系结构

的简单比较 ]在传统架构下，消息“消息在存储之前已同步”：

对于在线用户，该消息将直接实时实时同步到在线接收者。消息成功同步后，将不会保留。对于脱机用户或无法实时同步消息时，消息将保留到脱机库中，并且当接收方重新连接时，所有未读消息将从脱机库中提取。脱机库中的消息成功同步到收件人之后，邮件将从离线库中删除。在传统的邮件系统中，服务器的主要工作是维护发送方和接收方的连接状态，并提供联机消息同步和脱机消息缓存功能，以确保可以将消息从发送方传递到邮件。接收器。服务器不保留消息，因此它不支持消息漫游。

在现代体系结构中，先存储消息然后再进行同步：

先存储然后再进行同步的好处是，如果接收方确认已收到消息，则消息必须具有被保存在云中。而邮件将有两个要保存的库，一个是邮件存储库，用于保存所有会话的所有邮件，主要用于支持邮件漫游。另一个是消息同步库，主要用于接收方的多端同步。

从发件人发送消息并由服务器转发后，服务器将首先将消息保存到消息存储库，然后再将其保存到消息同步库。消息保留后，在线接收者将直接选择在线推送。但是在线推送不是必不可少的路径，而只是更好的消息传递路径。

对于无法在线或离线推送的接收者，还有另一种统一的消息同步方法。接收方将主动从服务器中拉出所有未同步的消息，但是服务器不知道接收方何时进行同步以及它们将在何处同步消息，因此必须要求服务器保存所有需要接收的同步消息。消息同步库的主要作用。对于新的同步设备，将需要进行消息漫游，这是消息存储库的主要作用。在消息存储中，您可以提取任何会话的全部历史消息。

以上是传统建筑和现代建筑之间的简单比较。在现代体系结构上，整个消息同步和存储过程并没有变得太复杂，但是它可以实现多端同步和消息漫游。现代体系结构的核心是两个消息库“消息同步库”和“消息存储库”，这是消息同步和存储的核心基础。本文的下一部分将重点介绍这两个库的设计和实现。

4。时间轴模型

在分析“消息同步库”和“消息存储库”的设计和实现之前，将在本章中介绍逻辑模型-时间轴。时间轴模型将帮助我们简化消息同步和存储模型理解，并且消息库的设计和实现也围绕时间轴的特征和需求。

讨论现代IM系统中聊天消息的同步和存储方案。

▲时间轴模型

如图所示是时间轴模型的抽象表示，时间轴可以是简单地理解为消息队列，但是此消息队列具有以下特征：

每个消息都有一个序列ID（SeqId），队列后面的消息的SeqId必须大于上一个消息的SeqId ，即必须保证SeqId正在增加，但不需要严格增加；

总是在末尾添加新消息，以确保新消息的SeqId始终大于队列中已有的消息；

可以根据SeqId随机地放置在特定的位置。阅读消息，也可以任意阅读给定范围内的所有消息。

使用这些功能，可以使用时间轴轻松实现消息的同步。在该图中的示例中，消息的发送者是A，消息的接收者是B。同时，B具有多个接收者，即B1，B2和B3。 A向B发送一条消息。该消息需要同步到B的多个端点。要同步的消息通过时间轴交换。 A发送给B的所有消息都将存储在此时间轴中，并且B的每个接收端将从该时间轴中独立提取消息。每个接收端的同步完成后，将在本地记录最新同步消息的SeqId，即以最新位置作为下一次消息同步的起点。服务器将不会保存各端的同步状态，并且各端可以随时随地开始提取消息。

消息漫游也基于时间轴。与消息同步的唯一区别是，消息漫游要求服务器能够在时间轴中保留所有数据。

基于时间轴，很容易从逻辑模型中了解如何在服务器端实现消息同步和存储，并且支持高级功能，例如多端同步和消息漫游。着手实施的困难主要是如何将逻辑模型映射到物理模型。对数据库执行时间轴有哪些要求？我们应该选择哪种数据库？这个这些是接下来将要讨论的问题。

5。消息存储模型

关于现代IM系统中聊天消息的同步和存储方案的讨论_3.png

▲基于时间轴的消息存储模型

时间轴的消息存储模型，消息存储需要每个会话对应一个独立的时间轴。如示例所示，A和B / C / D / E / F进行对话，每个对话对应一个独立的时间轴，每个时间轴内存包含此对话中的所有消息，服务器将响应每个时间轴使其持久化。服务器可以将所有消息保留在所有会话的时间轴中，因此可以漫游消息。

6。消息同步模型

消息同步模型将比消息存储模型稍微复杂一些。消息同步通常具有两种不同的模式：读扩散和写扩散，分别对应于不同的时间轴物理模型。

讨论现代IM系统中聊天消息的同步和存储方案_4.png

▲不同的时间轴模型分别对应于读扩散和写扩散的两种不同同步模式

读取扩散和写入扩散的两种不同同步模式下对应的不同时间轴模型。根据图中的示例，作为消息接收者的A与B / C / D / E / F进行一次对话，并且每次对话都需要将新消息同步到A的特定一端。让我们看看如何以读扩散和写扩散两种模式同步消息。

阅读扩散：

在消息存储模型中，每个会话的时间轴存储该会话的全部消息量。在读-扩散消息同步模式下，每个会话中生成的新消息只需写入一次用于存储的时间线，接收者就可以从该时间线中提取新消息。

优点是消息只需要写入一次。与写扩散模式相比，可以大大减少消息的写入次数，尤其是在组消息场景中。但是它的缺点是比较明显的，接收方取消消息同步的逻辑将相对复杂且效率低下。接收端需要拉每个会话一次以获取所有消息。读取会大大放大，并且会生成许多无效的读取，因为并非每个会话都会有新的消息。

写扩散：

写扩散消息同步模式，需要有一个专用于消息同步的附加时间轴，通常每个接收端将有一个独立的同步时间轴，用于存储所有消息需要同步到此接收端。

每个会话中的消息将生成多次写入。除了编写用于存储消息的会话时间线之外，还需要编写要同步的接收端的同步时间线。在个人对话中，该消息将被写入两次。除了写入此对话的存储时间轴外，您还需要写入参与此对话的两个收件人的同步时间轴。在小组方案中，写作将被进一步放大。如果该组有N位参与者，则每条消息都需要编写N次。

写扩散同步模式的优点在于，接收端的消息同步逻辑将非常简单，您只需从其同步时间轴中读取一次即可，这大大降低了消息所需的读取压力同步。缺点是，消息编写将被放大，尤其是对于团体方案。

在IM的应用场景中，通常选择写扩散的消息同步模式。

在IM场景中，一条消息只会生成一次，但是会被多次读取。这是多读少写的典型方案。消息的读写比约为10：1。如果使用读扩散同步模式，则整个系统的读写比率将扩大到100：1。

一个经过优化的系统必须通过设计平衡此读写压力，以避免任何一维的读写接触天花板。因此，在诸如IM系统的场景中，通常采用写扩散的同步模式来平衡读写，并平衡100：1至30:30的读写比。

当然，编写扩散的同步模式还需要处理一些极端情况，例如成千上万的大型团体。对于这种极端的写入扩散方案，将退化为使用读取扩散。一个简单的IM系统通常会在产品级别上限制这一庞大群体的存在。对于高级IM系统，将使用读写扩散的混合同步模式来满足此类产品的需求。使用混合模式时，它将基于不同类型的数据和不同的读写负载来决定是使用写扩散还是使用读扩散。

7。典型的架构设计

现在如上图所示，关于生成IM系统_xxx.jpg

中聊天消息的同步和存储方案的讨论是一种典型的消息系统体系结构。

此典型的消息系统体系结构包含几个重要组件：

1）结束：作为消息的发送和接收端，它通过连接到消息服务器来发送和接收消息。

2）消息服务器：一组无状态服务器，可以水平扩展以处理消息的发送和接收请求，并连接到后端消息系统。

3）消息队列：用于新写入消息的缓冲区队列，以及消息系统的消息前存储，用于消息的峰值和谷值填充以及异步消耗。

4）消息处理：一组无状态消耗处理服务器，用于异步消耗消息队列中的消息数据，以处理消息的持久性和写入扩散的同步。

5）消息存储和索引库：持久存储消息，每个会话对应于消息存储的时间轴，对存储的消息进行索引以实现消息检索。

6）消息同步库：

编写扩散型同步消息。每个用户的收件箱都对应一个时间轴。同步库中的消息不需要永久保存。通常，为消息设置生命周期。

新消息将在最后发送，通常消息正文将带有消息ID（用于重复数据删除），逻辑时间戳记（用于排序），消息类型（控制消息，图片消息或文本消息等）。），消息正文等。