零基础IM开发入门(四)：什么是IM系统的消息时序一致性？

本文引用了沈剑《如何保证IM实时消息的“时序性”与“一致性”？》一文的图片和内容（由于本人太懒，图我没重新画），原文链接在文末。

1、引言

本文接上篇《零基础IM开发入门(三)：什么是IM系统的可靠性？》，讲解IM系统中消息时序的一致性问题。

所谓的一致性，在IM中通常指的是消息时序的一致性，那就是：

• 1）聊天消息的上下文连续性；
• 2）聊天消息的绝对时间序。
  

再具体一点，IM消息的一致性体现在：

• 1）单聊时：要保证发送方发出聊天消息的顺序与接收方看到的顺序一致；
• 2）群聊时：要保证所有群员看到的聊天消息，与发送者发出消息时的绝对时间序是一致的。
  

IM系统中消息时序的一致性问题是个看似简单，实则非常有难度的技术热点话题之一，本文尽量以通俗简显的文字为你讲解IM消息时序一致性问题的产品意义、发生原因、解决思路等。

                  

阅读对象：本系列文章主要阅读对象为零IM基础的开发者或产品经理，目标是告诉你“IM系统是什么？”，尽量不深入探讨具体的技术实现，确保通俗易懂，老少皆宜。

如您想从技术维度系统学习IM技术并着手自已的IM开发（即解决“IM系统要怎么做？”这个疑问），请从此文开始：《新手入门一篇就够：从零开发移动端IM》。

本文已同步发布于“即时通讯技术圈”公众号，欢迎关注。公众号上的链接是：点此进入。

2、系列文章

• 《零基础IM开发入门(一)：什么是IM系统？》
• 《零基础IM开发入门(二)：什么是IM系统的实时性？》
• 《零基础IM开发入门(三)：什么是IM系统的可靠性？》
• 《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》（* 本文）
• 《零基础IM开发入门(五)：什么是IM系统的安全性？ (稍后发布)》
• 《零基础IM开发入门(六)：什么是IM系统的的心跳机制？ (稍后发布)》
• 《零基础IM开发入门(七)：如何理解并实现IM系统消息未读数？ (稍后发布)》
• 《零基础IM开发入门(八)：如何理解并实现IM系统的多端消息漫游？ (稍后发布)》
  

3、消息时序的一致性，对于IM的意义

现如今，由于移动互联网的普及，现代人的实际社交关系，几乎完全是靠IM这种即时通讯社交工具所组织起来的，IM这种工具的重要性不言而喻。

IM在现代人的生活中，越来越重要，但也越来平常。现在想联系一个人，第一时间想到的不是打个电话，而是发个“微信”或“QQ”。是的，IM这玩意承载的意义越来越多。

消息时序的一致性问题，对于IM的意义，毫无疑问带来的不只是简简单单的所谓用户体验问题。我们来看看例子。

假设：你跟女神的表白正进入到关键阶段，聊着聊着就因为这烂IM，导致聊天消息前言不搭后语，此刻1000公里外你的女神真一脸蒙逼的盯着手机看你的“醉话”，后果是多么严重——这半年来的“舔狗”生活、忍辱负重，算是白白被程序员这群“格子衫”、“地中海”们给祸害了。



再往严重了说，就因为这烂IM，让你失去了这难得的借助女神优良基因，改造家族后代颜值的绝佳机会，无不让人痛心疾首。。。

上面这个例子，说的还只是单聊，如果是群聊，则问题可能还会被无限放大：试想一个技术交流群，正在激烈的争吵着“php是世界最好语言”这种话题的时候，忽然就想砸手机了，不是因为吵的太凶，而因为消息顺序全乱完全没法看，已经严重影响键盘侠们积极发表个人意见了。

4、凭什么说保证消息时序的一致性很困难？

4.1基本认知

在普通IM用户的眼里，消息无非是从一台手机传递到另一台手机而已，保证时序有何困难？

是的，普通用户这么认为，从技术上讲，他只是单纯的将IM消息的收发过程理解为单线程的工作模式而已。

实际上，在IM这种高性能场景下，服务端为了追求高吞吐、高并发，用到了多线程、异步IO等等技术。

在这种情况下，“高并发”与“顺序”对于IM服务端来说，本来就是矛盾的，这就有点鱼与熊掌的味道了（两者很难兼得）。

所以，要实现IM场景下的消息时序一致性，需要做出权衡，而且要考虑的技术维度相当多。这就导致具体技术实施起来没有固定的套路，而由于开发者技术能力的参差不齐，也就使得很多IM系统在实际的效果上会有较大问题，对于用户而言也将直接在产品体验上反应出来。

下面将具体说明技术难点所在。

4.2没有全局时钟

如上图所示，一个真正堪用的生产系统，显示不可能所有服务都跑在一台服务器上，分布式环境是肯定的。

那么：在分布式环境下，客户端+服务端后台的各种后台服务，都各自分布在不同的机器上，机器之间都是使用的本地时钟，没有一个所谓的“全局时钟”（也没办法做到真正的全局时钟），那么所谓的消息时序也就没有真正意义上的时序基准点。所以消息时序问题显然不是“本地时间”可以完全决定的。

4.3多发送方问题

服务端分布式的情况下，不能用“本地时间”来保证时序性，那么能否用接收方本地时间表示时序呢？

遗憾的是，由于多个客户端的存在（比如群聊时），即使是一台服务器的本地时间，也无法表示“绝对时序”。

如上图所示：绝对时序上，APP1先发出msg1，APP2后发出msg2，都发往服务器web1，网络传输是不能保证msg1一定先于msg2到达的，所以即使以一台服务器web1的时间为准，也不能精准描述msg1与msg2的绝对时序。

4.4多接收方问题

多发送方不能保证时序，假设只有一个发送方，能否用发送方的本地时间表示时序呢？遗憾的是，由于多个接收方的存在，无法用发送方的本地时间，表示“绝对时序”。

如上图，绝对时序上，web1先发出msg1，后发出msg2，由于网络传输及多接收方的存在，无法保证msg1先被接收到先被处理，故也无法保证msg1与msg2的处理时序。

4.5网络传输与多线程问题

既然多发送方与多接收方都难以保证绝对时序，那么假设只有单一的发送方与单一的接收方，能否保证消息的绝对时序一致性呢？

结论是悲观的，由于网络传输与多线程的存在，这仍然不行。

如上图所示，web1先发出msg1、后发出msg2，即使msg1先到达（网络传输其实还不能保证msg1先到达），由于多线程的存在，也不能保证msg1先被处理完。

5、如何保证绝对的消息时序一致性？

通过上一章内容的总结，我们已经对IM中消息时序一致性问题所产生的缘由，有了较为深刻的认识。

从纯技术的角度来说，假设：

• 1）只有一个发送方；
• 2）一个接收方；
• 3）上下游连接只有一条socket连接；
• 4）通过阻塞的方式通讯。
  

这样的情况下，难道不能保证先发出的消息被先处理，进而被先展示给消息的接收者吗？

是的，可以！

但实际生产情况下不太可能出现这种IM系统，必竟单发送方、单接收方、单socket连接、阻塞方式，这样的IM一旦做出来，产品经理会立马死给你看。。。

6、实用的优化思路

6.1一对一单聊的消息一致性保证思路

假设两人一对一聊天，发送方A依次发出了msg1、msg2、msg3三条消息给接收方B，这三条消息该怎么保证显示时序的一致性（发送与显示的顺序一致）？

我们知道，发送方A依次发出的msg1、msg2、msg3三条消息，到底服务端后，再由服务端中转发出时，这个顺序由于多线程的网络的问题，是有可能乱序的。

那么结果就可能是这样：


如上图所示，会出现与发出时的消息时序不一致问题（收到的消息顺序是：msg3、msg1、msg2）。

不过，实际上一对一聊天的两个人，并不需要全局消息时序的一致（因为聊天只在两人的同一会话在发生），只需要对于同一个发送方A，发给B的消息时序一致就行了。

常见优化方案，在A往B发出的消息中，加上发送方A本地的一个绝对时序（比如本机时间戳），来表示接收方B的展现时序。

那么当接收方B收到消息后，即使极端情况下消息可能存在乱序到达，但因为这个乱序的时间差对于普通用户来说体感是很短的，在UI展现层按照消息中自带的绝对时序排个序后再显示，用户其实是没有太多感知的。

6.2多对多群聊的消息一致性保证思路

假设N个群友在一个IM群里聊天，应该怎样保证所有群员收到消息的显示时序一致性呢？

首先：不能像一对一聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时间也不一致。

或许：我们可以利用服务器的单点做序列化。



如上图所示，此时IM群聊的发送流程为：

• 1）sender1发出msg1，sender2发出msg2；
• 2）msg1和msg2经过接入集群，服务集群；
• 3）service层到底层拿一个唯一seq，来确定接收方展示时序；
• 4）service拿到msg2的seq是20，msg1的seq是30；
• 5）通过投递服务讲消息给多个群友，群友即使接收到msg1和msg2的时间不同，但可以统一按照seq来展现。
  

这个方法：

• 1）优点是：能实现所有群友的消息展示时序相同；
• 2）缺点是：这个生成全局递增序列号的服务很容易成为系统瓶颈。
  

还有没有进一步的优化方法呢？

从技术角度看：群消息其实也不用保证全局消息序列有序，而只要保证一个群内的消息有序即可，这样的话，“消息id序列化”就成了一个很好的思路。



上图这个方案中，service层不再需要去一个统一的后端拿全局seq（序列号），而是在service连接池层面做细小的改造，保证一个群的消息落在同一个service上，这个service就可以用本地seq来序列化同一个群的所有消息，保证所有群友看到消息的时序是相同的。

关于IM的系统架构下使用怎么样实现消息序列化，或者说全局消息ID的生成方案，这又是另一个很热门的技术话题。

有兴趣，可以深入阅读下面这个系列：

• 《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
• 《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
• 《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
• 《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
• 《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
• 《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
  

这个系列中，尤其微信的趋势递增ID生成思路（注意：趋势递增不是严格递增，趋势递增意味着中问有ID被跳过也没事），对于分布式IM的消息ID来说是非常切实可行的。

是的，对于IM系统来说，绝对意义上的时序很难保证，但通过服务端生成的单调递增消息ID的方式，利用递增ID来保证时序性，也是一个很可性的方案。

7、小结一下

IM系统架构下，消息的绝对时序是很困难的，原因多种多样，比如：没有全局时钟、多发送方、多接收方、多线程、网络传输不确定性等。

一对一单聊时，其实只需要保证发出的时序与接收的时序一致，就基本能让用户感觉不到乱序了。

多对多的群聊情况下，保证同一群内的所有接收方消息时序一致，也就能让用户感觉不到乱序了，方法有两种，一种单点绝对时序，另一种实现消息id的序列化（也就是实现一种全局递增消息ID）。

8、参考资料

[1] 如何保证IM实时消息的“时序性”与“一致性”？，作者：沈剑
[2] 一个低成本确保IM消息时序的方法探讨，作者：封宇

附录：更多IM开发热门技术点

• 《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
• 《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
• 《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
• 《移动端IM中大规模群消息的推送如何保证效率、实时性？》
• 《移动端IM开发需要面对的技术问题》
• 《开发IM是自己设计协议用字节流好还是字符流好？》
• 《请问有人知道语音留言聊天的主流实现方式吗？》
• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《一个低成本确保IM消息时序的方法探讨》
• 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
• 《谈谈移动端 IM 开发中登录请求的优化》
• 《移动端IM登录时拉取数据如何作到省流量？》
• 《浅谈移动端IM的多点登录和消息漫游原理》
• 《完全自已开发的IM该如何设计“失败重试”机制？》
• 《微信对网络影响的技术试验及分析（论文全文）》
• 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
• 《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
• 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
• 《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
• 《IM的扫码登录功能如何实现？一文搞懂主流应用的扫码登录技术原理》
• 《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
  

催更第五章~哈哈哈哈哈

引用：Rayman 发表于 2020-11-30 17:59
催更第五章~哈哈哈哈哈

先别催，我还得酝酿一下。。。

同一个人如果是以TCP与服务端连接，任一时刻客户端总是与某1台服务器连接，只需在接入服务器为每一条消息打上时间戳，毫秒或微秒级的，更极致的：时间戳相同时，加上序列号。对发送者是唯一了。这样，与后面有多少个服务、多少个并发线程都不相关。

感谢～通俗易懂，催更后续，哈哈～

第五章呢 看着上瘾了 无法自拔 咋整

现在的做法都是服务端存储，没有所谓的ack确认，是不是和IM跑偏了。

引用：某非著名程序 发表于 2021-03-10 13:42
现在的做法都是服务端存储，没有所谓的ack确认，是不是和IM跑偏了。

实时消息，必须得实时传啊

又看了一遍。我们功能支持多端、漫游。
每次客户端重连服务端都会推送最近的10个会话10条消息或者未读会话的10条消息，用于展示会话的最近一条和进聊天界面的一屏消息。滑动会加载历史数据。
如果有新消息，服务端会推送到端。用于实时显示。
这样的逻辑会有问题吗？看了楼主的一系列文章，发现我们这种做法根本没有ack，我自己也是很疑惑。

引用：某非著名程序 发表于 2021-03-14 19:56
又看了一遍。我们功能支持多端、漫游。
每次客户端重连服务端都会推送最近的10个会话10条消息或者未读会话 ...

ACK是为了保证百分百准确性，你在初期的版本时，先不用考虑这个，能把功能逻辑实现了再说，后绪版本再逐步精进

好的。明白了

群聊时，server去单点拿seq做序列化，这里也有些问题。多个sender发到server的消息，server收到后也可能是乱序的，此时拿到seq得到的顺序不能保证一定和发送方顺序一样，只可以保证多个接收者之间的展示顺序是一样的。

引用：weixiaoyao 发表于 2021-03-25 11:38
群聊时，server去单点拿seq做序列化，这里也有些问题。多个sender发到server的消息，server收到后也可能是 ...

在im的场景下，这样其实也没太大问题。
我昨天又回看了作者的另一篇时序的文章，2年前我也提过类似的问题，作者给过解答。
O了

催跟催跟！

我觉的LB的时候用一致性hash会好些，加减服务器影响面小

捉虫：
原文："首先：不能像一对聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时间也不一致"
应该是："首先：不能像一对一聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时间也不一致"

引用：肥猫布里奇高 发表于 2023-04-09 20:04
捉虫：
原文："首先：不能像一对聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时 ...

已修订，非常感谢