如何保证IM实时消息的“时序性”与“一致性”？

本文作者沈剑，原创发表于“架构师之路”公众号，原题“消息“时序”与“一致性”为何这么难？”，本次内容有修订和改动。

1、前言

我们都知道，一个典型的分布式系统中，很多业务场景都需要考虑消息投递的时序，例如：

• IM中单聊消息投递：保证发送方发送顺序与接收方展现顺序一致；
• IM中群聊消息投递：保证所有接收方展现顺序一致；
• 电商充值支付消息：保证同一个用户发起的请求在服务端执行序列一致。
  

实时消息时序和一致性是分布式系统架构设计中非常难的问题（尤其IM应用这种以消息为中心的应用形态），困难在哪？有什么常见优化实践？这就是本文要讨论的内容。

2、IM开发干货系列文章

本文是系列文章中的第3篇，总目录如下：

• 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
• 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
• 《如何保证IM实时消息的“时序性”与“一致性”？》（本文）
• 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
• 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
• 《移动端IM登录时拉取数据如何作到省流量？》
• 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
• 《浅谈移动端IM的多点登陆和消息漫游原理》
• 《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
• 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
• 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
• 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
• 《IM群聊消息的已读回执功能该怎么实现？》
• 《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
• 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
• 《一个低成本确保IM消息时序的方法探讨》
• 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
• 《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
• 《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
• 《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
• 《IM的扫码登功能如何实现？一文搞懂主流应用的扫码登陆技术原理》
• 《IM要做手机扫码登陆？先看看微信的扫码登录功能技术原理》
• 《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
• 《IM开发实战干货：我是如何解决大量离线聊天消息导致客户端卡顿的》
• 《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
  

另外，如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

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

为什么分布式环境下，即时消息的时序难以保证，这边简要分析了几点原因：

3.1时钟不一致

分布式环境下，有多个客户端、有web集群、service集群、db集群，他们都分布在不同的机器上，机器之间都是使用的本地时钟，而没有一个所谓的“全局时钟”，所以不能用“本地时间”来完全决定消息的时序。

3.2多客户端（发送方）

多服务器不能用“本地时间”进行比较，假设只有一个接收方，能否用接收方本地时间表示时序呢？遗憾的是，由于多个客户端的存在，即使是一台服务器的本地时间，也无法表示“绝对时序”。

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

3.3服务集群（多接收方）

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

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

3.4网络传输与多线程

多发送方与多接收方都难以保证绝对时序，假设只有单一的发送方与单一的接收方，能否保证消息的绝对时序呢？结论是悲观的，由于网络传输与多线程的存在，仍然不行。

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

3.5怎么保证绝对时序

通过上面的分析，假设只有一个发送方，一个接收方，上下游连接只有一条连接池，通过阻塞的方式通讯，难道不能保证先发出的消息msg1先处理么？
答案是：可以，但吞吐量会非常低，而且单发送方单接收方单连接池的假设不太成立，高并发高可用的架构不会允许这样的设计出现。

4、生产环境下的优化方法总结

4.1以客户端或者服务端的时序为准

多客户端、多服务端导致“时序”的标准难以界定，需要一个标尺来衡量时序的先后顺序。

不过，我们可以根据业务场景，以客户端或者服务端的时间为准，例如：

• 邮件展示顺序：其实是以客户端发送时间为准的，潜台词是，发送方只要将邮件协议里的时间调整为1970年或者2970年，就可以在接收方收到邮件后一直“置顶”或者“置底”；
• 秒杀活动时间判断：肯定得以服务器的时间为准，不可能让客户端修改本地时间，就能够提前秒杀。
  

4.2服务端能够生成单调递增的id

这个是毋庸置疑的，不展开讨论，例如利用单点写db的seq/auto_inc_id肯定能生成单调递增的id，只是说性能及扩展性会成为潜在瓶颈。对于严格时序的业务场景，可以利用服务器的单调递增id来保证时序。

关于IM的系统架构下使用怎么样的消息ID生成方案，这又是另一个很热门的技术话题。

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

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

4.3大部分业务能接受误差不大的趋势递增id

消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求：

• 同1s内发布的聊天消息时序乱了；
• 同1s内发布的帖子排序不对；
• 用1s内发起的秒杀，由于服务器多台之间时间有误差，落到A服务器的秒杀成功了，落到B服务器的秒杀还没开始，业务上也是可以接受的（用户感知不到）。
  

所以，大部分业务，长时间趋势递增的时序就能够满足业务需求，非常短时间的时序误差一定程度上能够接受。关于绝对递增id，趋势递增id的生成架构，详见文章《细聊分布式ID生成方法》，此处不展开。

另外，微信团队分享的这篇《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》，对于IM这种场景下的趋势递增消息ID生成有很强的借鉴意义。

4.4利用单点序列化，可以保证多机相同时序

数据为了保证高可用，需要做到进行数据冗余，同一份数据存储在多个地方，怎么保证这些数据的修改消息是一致的呢？

我们可以利用的就是“单点序列化”：

• 先在一台机器上序列化操作；
• 再将操作序列分发到所有的机器，以保证多机的操作序列是一致的，最终数据是一致的。
  

► 典型场景一：数据库主从同步

数据库的主从架构，上游分别发起了op1,op2,op3三个操作，主库master来序列化所有的SQL写操作op3,op1,op2，然后把相同的序列发送给从库slave执行，以保证所有数据库数据的一致性，就是利用“单点序列化”这个思路。

► 典型场景二：GFS中文件的一致性

GFS(Google File System)为了保证文件的可用性，一份文件要存储多份，在多个上游对同一个文件进行写操作时，也是由一个主chunk-server先序列化写操作，再将序列化后的操作发送给其他chunk-server，来保证冗余文件的数据一致性的。

4.5IM中单对单聊天，怎么保证发送顺序与接收顺序一致

IM中单人聊天的需求，发送方A依次发出了msg1，msg2，msg3三个消息给接收方B，这三条消息能否保证显示时序的一致性（发送与显示的顺序一致）？

答案是：

• 如果利用服务器单点序列化时序，可能出现服务端收到消息的时序为msg3，msg1，msg2，与发出序列不一致；
• 业务上不需要全局消息一致，只需要对于同一个发送方A，ta发给B的消息时序一致就行，常见优化方案，在A往B发出的消息中，加上发送方A本地的一个绝对时序，来表示接收方B的展现时序。
  

msg1{seq:10, receiver:B,msg:content1 }
msg2{seq:20, receiver:B,msg:content2 }
msg3{seq:30, receiver:B,msg:content3 }

潜在问题：如果接收方B先收到msg3，msg3会先展现，后收到msg1和msg2后，会展现在msg3的前面。

无论如何，是按照接收方收到时序展现，还是按照服务端收到的时序展现，还是按照发送方发送时序展现，是pm需要思考的点，技术上都能够实现（接收方按照发送时序展现是更合理的）。总之，需要一杆标尺来衡量这个时序。

4.6IM群聊消息，怎么保证各接收方收到顺序一致

IM群聊消息的需求，N个群友在一个群里聊，怎么保证所有群友收到的消息显示时序一致？

答案是：

• 不能再利用发送方的seq来保证时序，因为发送方不单点，时间也不一致；
• 可以利用服务器的单点做序列化。
  

此时IM群聊的发送流程为：

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

这个方法能实现，所有群友的消息展示时序相同。缺点是，这个生成全局递增序列号的服务很容易成为系统瓶颈，还有没有进一步的优化方法呢？

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

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

关于id串行化的细节，可详见《利用id串行化解决缓存与数据库一致性问题》，此处不展开。

5、本文小结

1）分布式环境下，消息的有序性是很难的，原因多种多样：时钟不一致，多发送方，多接收方，多线程，网络传输不确定性等；
2）要“有序”，先得有衡量“有序”的标尺，可以是客户端标尺，可以是服务端标尺；
3）大部分业务能够接受大范围趋势有序，小范围误差；绝对有序的业务，可以借助服务器绝对时序的能力；
4）单点序列化，是一种常见的保证多机时序统一的方法，典型场景有db主从一致，gfs多文件一致；
5）单对单聊天，只需保证发出的时序与接收的时序一致，可以利用客户端seq；
6）群聊，只需保证所有接收方消息时序一致，需要利用服务端seq，方法有两种，一种单点绝对时序，另一种id串行化。

（原文链接：点此进入）

58这哥们真是勤奋，工作这么忙还能静下心来撸文章，赞一个

那么怎么去保证呢

单对单聊天中， 那三条消息，如果一条消息 msg2 因为网络问题，服务器的notice 接收方出现丢包。
接收方的只收到了 msg1 , msg3 ， 这种情况显示 msg1，msg3吗。还是会等 msg2 收到了再一起显示 msg1, msg2, msg3 吗。

引用：copyleft 发表于 2017-06-11 23:51
单对单聊天中， 那三条消息，如果一条消息 msg2 因为网络问题，服务器的notice 接收方出现丢包。
接收方的 ...

你可以在客户端进行处理，你观察一下微信和qq，不过可能会因为国内的网络太好而很难碰到这种情况的话，你可以下载skype去试，你能很明显的观察到，skype因为在中国没有服务器，经常出现连发的几条消息中有间隔的消息迟到，但在客户端显示时会及时插入到它应该在的位置。

像skype这种的处理方法，其实就是现在移动端im的客户端处理消息乱序的作法。仅供参考。

引用：JackJiang 发表于 2017-06-12 10:13
你可以在客户端进行处理，你观察一下微信和qq，不过可能会因为国内的网络太好而很难碰到这种情况的话，你 ...

赞，学到了，

你好，请问怎么保证单聊中对方发送的消息和自己的消息之间的有序性？你上面的方案只保证了单聊中一方消息的有序性。

引用：伤经纪业 发表于 2017-11-21 17:07
你好，请问怎么保证单聊中对方发送的消息和自己的消息之间的有序性？你上面的方案只保证了单聊中一方消息的 ...

你这个问题，仿佛打开了一个新的世界，我想都没想过

引用：mw-im 发表于 2018-01-03 10:50
没有完美而又简洁的解决方案，其实统一使用server端的时间戳来对消息排序，相对来说是一个经济的解决方案 ...

在集群的情况下，要保证服务端各实例的时间戳一致性，也是个麻烦事，所以没有完美的方案

good

学习了

纯粹的干货

很好的一个学习文章！

这个，其实没有解决消息有有序的问题。会先收到消息2，3，然后收到消息1，用户看到消息1突然看到显示到前面去了。是不是，有点儿可笑？
我有列先进的方案

引用：snowingximen 发表于 2018-11-28 14:59
这个，其实没有解决消息有有序的问题。会先收到消息2，3，然后收到消息1，用户看到消息1突然看到显示到前面 ...

你分享你的思路

群聊时当多个发送者A,B都发送群消息时，服务端序列方式也无法保证多个发送者的消息序列，假设A先发，B后发，接收方C收到并显示的消息，可能是先B后A，仍是乱序，服务端序列化只能保证多个接收方C,D,E收到并显示的都是先B后A。这该如何能保证接收方显示的百分百和发送方的顺序一致呢？或者是否有必要保证这种顺序呢？

引用：weixiaoyao 发表于 2018-12-27 17:55
群聊时当多个发送者A,B都发送群消息时，服务端序列方式也无法保证多个发送者的消息序列，假设A先发，B后发 ...

im这种产品很讲究现实情况。

我们回归到现实：假设你现在正在一个QQ群里，一般正常的群聊，大家都是你一句我一句，按打字速度，和大家的理解速度，再频繁的聊天，基本上都是几秒才出现一条，且很有规律，因为对话总是你一句我一句。这种情况下，每条消息的间隔，至少有几秒钟，按照服务器的处理效率来说，本身也比较难以出现后一条消息先于前一条送达。

你可能坚持认为，肯定会存在消息一条接一条，而且间隔极短，那不就有很大几率出现了吗？但：那就是如果是这样情况，那还是聊天吗？不可能这个在收到那个人发出的消息瞬间就发出了自已的消息，因为他需要理解时间、需要打字时间。你可能还坚持说，肯定有这种情况，但换个思路想想，极短的时间内群内出现大量消息，那不这就是刷屏吗，哪还是聊天？既然是刷屏消息，它到底有没有乱序，你作为群员怎么判断的出来（因为没有上下文关联意义）？或者有什么意义要判断出来？

所以。我的个人观点是，群聊消息顺序这种事情要想保证理论上的绝对正确，难度很高，但回归现实，这种问题可以很简单的处理，不需要纠结绝对的理论。

学习了，不过要做到全一致性真的很困难