别再用 Netty 写 helloWorld 了, 进来了解一下实时聊天系统在这个高度信息化的移动互联网时代，IM（In

政采云技术团队.png

依韵.png

1. IM 介绍

1.1 背景

在这个高度信息化的移动互联网时代，IM（Instant Messaging，即时通讯）类产品已经成为生活必备品，例如钉钉、微信、QQ。微信已经成长为一个生态型产品，但其核心功能仍是IM。IM系统中最核心的部分是消息系统，消息系统中最核心的功能是消息同步、存储：

消息同步：指将消息完整的、快速的从发送方传递到接收方。消息同步系统最重要的衡量指标就是消息传递的实时性、完整性以及能支撑的消息规模。在功能上，至少要支持在线和离线推送，有些IM系统还支持多端同步。
消息存储：指消息的持久化保存。传统消息系统通常只能支持消息在接收端的本地存储，数据基本不具备可靠性。现代消息系统能支持消息在服务端的在线存储，功能上对应的就是消息漫游，消息漫游的好处是可以实现账号在任意端登录查看所有历史消息。

1.2 传统架构 vs 现代架构

传统架构

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

现代架构下，消息是先存储后同步。先存储后同步的好处是，如果接收方确认接收到了消息，那这条消息一定是已经在云端保存了。并且消息会有两个库来保存，一个是消息存储库，用于全量保存所有会话的消息，主要用于支持消息漫游。另一个是消息同步库，主要用于接收方的多端同步。消息从发送方发出后，经过服务端转发，服务端会先将消息保存到消息存储库，后保存到消息同步库。完成消息的持久化保存后，对于在线的接收方，会直接选择在线推送。但在线推送并不是一个必须路径，只是一个更优的消息传递路径。对于在线推送失败或者离线的接收方，会有另外一个统一的消息同步方式。接收方会主动的向服务端拉取所有未同步消息，但接收方何时来同步以及会在哪些端来同步消息对服务端来说是未知的，所以要求服务端必须保存所有需要同步到接收方的消息，这是消息同步库的主要作用。对于新的同步设备，会有消息漫游的需求，这是消息存储库的主要作用，在消息存储库中，可以拉取任意会话的全量历史消息。消息检索的实现依赖于对消息存储库内消息的索引，通常是一个近实时（NRT，near real time）的索引构建过程，这个索引同样是在线的。

1.3 IM技术架构

1.3.1 收件箱模型、发件箱模型

消息的同步一般有读扩散（也叫拉模式）和写扩散（也叫推模式）两种不同的方式，分别对应的是群聊和单聊。

读扩散：消息存储模型中，每个会话的时间线中保存了这个会话的全量消息。读扩散的消息同步模式下，每个会话中产生的新的消息，只需要写一次到其用于存储的表中，接收端从这个表中拉取新的消息。优点是消息只需要写一次，相比写扩散的模式，能够大大降低消息写入次数，特别是在群消息这种场景下。但其缺点也比较明显，接收端去同步消息的逻辑会相对复杂和低效。接收端需要对每个会话都拉取一次才能获取全部消息，读被大大的放大，并且会产生很多无效的读，因为并不是每个会话都会有新消息产生。
写扩散：写扩散的消息同步模式，需要有一个额外的表来专门用于消息同步，通常是每个接收端都会拥有一个独立的同步表（或者叫收件箱），用于存放需要向这个接收端同步的所有消息。每个会话中的消息，会产生多次写，除了写入用于消息存储的会话Timeline，还需要写入需要同步到的接收端的同步表。在个人与个人的会话中，消息会被额外写两次，除了写入这个会话的存储表，还需要写入参与这个会话的两个接收者的同步表。而在群这个场景下，写入会被更加的放大，如果这个群拥有N个参与者，那每条消息都需要额外的写N次。写扩散同步模式的优点是，在接收端消息同步逻辑会非常简单，只需要从其同步表中读取一次即可，大大降低了消息同步所需的读的压力。其缺点就是消息写入会被放大，特别是针对群这种场景。

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

2. 架构图

2.1 消息流架构图

这里消息模型采用经典的收件箱模型，并通过全局 seq 做消息对齐，这里带来架构的简化，体现了简单美的架构设计理念。我们知道收件箱模型的原理，也就知道了 seq 的概念，但如何在项目中做权衡和取舍，爱因斯坦曾经说过“事情应该力求简单，不过不能过于简单”，我们看到很多技术文章对收件箱模型和 seq 的滥用，要么系统设计复杂，要么过于简单，最后的结果是系统不稳定，消息可达率无法达到要求。以下我们简单讲解消息如何发送，系统如何简单解耦，接收方如何实时收到消息，并如何利用 seq 做全局消息对齐，确保消息百分百可达。

（1）绿色箭头表示用户A给B发送消息流程：用户A发送消息，msg_gateway 进行消息拆分，并落地 MQ，MQ 根据 userId 写入不同的 partition 后返回给 A 成功，消息发送流程结束。

（2）蓝色箭头表示A给B发送消息后，服务端给B推送消息流程：msg_transfer 通过MQ消费者监听消息达到，通过 redis 增加 userId 对应的 seq，并把 seq 和消息关联后写入 mongodb，并异步写入 mysql，前者用于离线消息存储，比如用户不在线或者推送失败时同步消息使用，后者主要做历史消息备份，用于管理后台或其他用途。写入成功后，再调用 pusher 推送，根据 B 所连接的 msg_gateway，进行消息推送（由于网络波动或者 B 不在线等原因，可能会推送失败）。

（3）粉色箭头表示 B 主动同步和服务端差量消息流程：客户端在任何有重连动作（包括重新登录、网络波动等）发生时，首先会获取自身在服务端最大的 seq，和本地 seq 做差值对比，把差值消息通过接口主动拉取到本地，这样完成了本地和服务端消息对齐。

分析完流程之后我们再围绕着消息库的建模来分析一下：

消息同步库

每个消息接收端保存有本地最新拉取的消息的SequenceID，每次拉取新消息均是从该SequenceID开始拉取消息。对同步库的查询会比较频繁，通常是对最新消息的查询，所以要求热数据尽量缓存在内存中，能提供高并发低延迟的查询。所以对同步库的配置，一般是需要SSD存储。消息如果已经同步到了所有的终端，则代表收件箱内的该消息已经被消费完毕，理论上可以清理。但设计上来说不做主动清理，而是给数据定义一个较短的生命周期来自动过期，一般定义为一周或者两周。数据过期之后，如果仍要同步拉取新消息，则需要退化到读扩散的模式，从存储库中拉取消息。

消息存储库

消息存储库中保存有每个会话的消息。发件箱内的消息支持按会话维度拉取消息，例如浏览某个会话内的历史消息则通过读取发件箱完成。一般来说，新消息通过在线推送或者查询同步库可投递到各个接收端，所以对存储库的查询会相对来说较少。而存储库用于长期存储消息，例如永久存储，相对同步库来说数据量会较大。所以存储库的选择一般是HDD，数据生命周期根据消息需要保存的时间来定，通常是一个较长的时间。

2.2 优点

针对 Kafka

对于前端的反馈，在消息入 Kafka 库之后，就能够返回成功，不仅响应的速度更快，消息的安全性也能够得到保障。

针对消息存储

而基于 Redis+MongoDB+MySQL 的消息同步、存储过程是比较完美的：

部分消息以及 SequenceID 等保存在 Redis 上，方便进行最新消息拉取和消息同步。
MongoDB 做消息的存储库，保存自定义天数的消息(如保存15天或一个月内的消息)，我们可以快速查询以及减少存储压力。
MySQL 可以实现消息的最终落地，一般不做消息查询，可以在后台管理界面连接 MySQL 进行消息管理。

本次就先介绍到这里，如果大家感兴趣，下次我写个详细的介绍下细节，欢迎留言讨论！

招贤纳士

政采云技术团队（Zero），一个富有激情、创造力和执行力的团队，Base 在风景如画的杭州。团队现有 500 多名研发小伙伴，既有来自阿里、华为、网易的“老”兵，也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com

微信公众号

文章同步发布，政采云技术团队公众号，欢迎关注