默认
打赏 发表评论 38
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
如何保证IM实时消息的“时序性”与“一致性”?
微信扫一扫关注!

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


1、前言


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

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

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

2、IM开发干货系列文章


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


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

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


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

3.1时钟不一致


1.jpg

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

3.2多客户端(发送方)


2.jpg

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

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

3.3服务集群(多接收方)


4.jpg

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

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

3.4网络传输与多线程


5.jpg

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

如上图,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生成方案,这又是另一个很热门的技术话题。

有兴趣,可以深入阅读下面这个系列:


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


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

  • 同1s内发布的聊天消息时序乱了;
  • 同1s内发布的帖子排序不对;
  • 用1s内发起的秒杀,由于服务器多台之间时间有误差,落到A服务器的秒杀成功了,落到B服务器的秒杀还没开始,业务上也是可以接受的(用户感知不到)。
所以,大部分业务,长时间趋势递增的时序就能够满足业务需求,非常短时间的时序误差一定程度上能够接受。关于绝对递增id,趋势递增id的生成架构,详见文章《细聊分布式ID生成方法》,此处不展开。

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

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


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

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

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

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

► 典型场景二:GFS中文件的一致性
7.jpg
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 }
8.jpg

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

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

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


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

答案是:

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

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

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

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

优化思路是:群消息其实也不用保证全局消息序列有序,而只要保证一个群内的消息有序即可,这样的话,“id串行化”就成了一个很好的思路。
10.jpg
这个方案中,service层不再需要去一个统一的后端拿全局seq,而是在service连接池层面做细小的改造,保证一个群的消息落在同一个service上,这个service就可以用本地seq来序列化同一个群的所有消息,保证所有群友看到消息的时序是相同的。

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

5、本文小结


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

(原文链接:点此进入

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:请教IM中netty+protobuf 如何更好地使用?下一篇:IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

本帖已收录至以下技术专辑

推荐方案
评论 38
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群里,一般正常的群聊,大家都是你一句我一句,按打字速度,和大家的理解速度,再频繁的聊天,基本上都是几秒才出现一条,且很有规律,因为对话总是你一句我一句。这种情况下,每条消息的间隔,至少有几秒钟,按照服务器的处理效率来说,本身也比较难以出现后一条消息先于前一条送达。

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

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

评分

2

查看评分

学习了,不过要做到全一致性真的很困难
签名: sdfs
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部