零基础 IM 开发入门 (四)：什么是 IM 系统的消息时序一致性？
本文引用了沈剑《如何保证 IM 实时消息的“时序性”与“一致性”？》一文的图片和内容（由于太懒，图没重新画），原文链接在文末。
1、引言
本文接上篇《零基础IM开发入门(三)：什么是IM系统的可靠性？》，讲解 IM 系统中消息时序的一致性问题。
所谓的一致性，在 IM 中通常指的是消息时序的一致性，那就是：
1）聊天消息的上下文连续性；
2）聊天消息的绝对时间序。
再具体一点，IM 消息的一致性体现在：
1）单聊时：要保证发送方发出聊天消息的顺序与接收方看到的顺序一致；
2）群聊时：要保证所有群员看到的聊天消息，与发送者发出消息时的绝对时间序是一致的。
IM 系统中消息时序的一致性问题是个看似简单，实则非常有难度的技术热点话题之一，本文尽量以通俗简显的文字为你讲解 IM 消息时序一致性问题的产品意义、发生原因、解决思路等。
2、系列文章
《零基础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生成算法》
这个系列中，尤其微信的趋势递增 ID 生成思路（注意：趋势递增不是严格递增，趋势递增意味着中问有 ID 被跳过也没事），对于分布式 IM 的消息 ID 来说是非常切实可行的。
是的，对于 IM 系统来说，绝对意义上的时序很难保证，但通过服务端生成的单调递增消息 ID 的方式，利用递增 ID 来保证时序性，也是一个很可性的方案。
7、小结一下
IM 系统架构下，消息的绝对时序是很困难的，原因多种多样，比如：没有全局时钟、多发送方、多接收方、多线程、网络传输不确定性等。
一对一单聊时，其实只需要保证发出的时序与接收的时序一致，就基本能让用户感觉不到乱序了。
多对多的群聊情况下，保证同一群内的所有接收方消息时序一致，也就能让用户感觉不到乱序了，方法有两种，一种单点绝对时序，另一种实现消息 id 的序列化（也就是实现一种全局递增消息 ID）。
8、参考资料
[1] 如何保证IM实时消息的“时序性”与“一致性”？，作者：沈剑
[2] 一个低成本确保IM消息时序的方法探讨，作者：封宇
（本文同步发布于：http://www.52im.net/thread-3189-1-1.html）
还未添加个人签名 2019.08.26 加入
开源IM框架MobileIMSDK、BeautyEye的作者。
评论