im即时通讯开发：如何保证消息的“时序性”与“一致性”

Posted 2022-04-29 wecloud1314

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

IM中单聊消息投递：保证发送方发送顺序与接收方展现顺序一致；

IM中群聊消息投递：保证所有接收方展现顺序一致；

电商充值支付消息：保证同一个用户发起的请求在服务端执行序列一致。

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

 

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

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

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

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

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

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

通过上面的分析，假设只有一个发送方，一个接收方，上下游连接只有一条连接池，通过阻塞的方式通讯，难道不能保证先发出的消息msg1先处理么？

答案是：可以，但吞吐量会非常低，而且单发送方单接收方单连接池的假设不太成立，高并发高可用的架构不会允许这样的设计出现。

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

 

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

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

邮件展示顺序：其实是以客户端发送时间为准的，潜台词是，发送方只要将邮件协议里的时间调整为1970年或者2970年，就可以在接收方收到邮件后一直“置顶”或者“置底”；

秒杀活动时间判断：肯定得以服务器的时间为准，不可能让客户端修改本地时间，就能够提前秒杀。

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

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

同1s内发布的聊天消息时序乱了；

同1s内发布的帖子排序不对；

用1s内发起的秒杀，由于服务器多台之间时间有误差，落到A服务器的秒杀成功了，落到B服务器的秒杀还没开始，业务上也是可以接受的（用户感知不到）。

所以，大部分业务，长时间趋势递增的时序就能够满足业务需求，非常短时间的时序误差一定程度上能够接受。

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

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

先在一台机器上序列化操作；

再将操作序列分发到所有的机器，以保证多机的操作序列是一致的，最终数据是一致的。

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

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

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

答案是：

如果利用服务器单点序列化时序，可能出现服务端收到消息的时序为msg3，msg1，msg2，与发出序列不一致；

业务上不需要全局消息一致，只需要对于同一个发送方A，ta发给B的消息时序一致就行，常见优化方案，在A往B发出的消息中，加上发送方A本地的一个绝对时序，来表示接收方B的展现时序。

msg1seq:10, receiver:B,msg:content1

msg2seq:20, receiver:B,msg:content2

msg3seq:30, receiver:B,msg:content3

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

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

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

答案是：

不能再利用发送方的seq来保证时序，因为发送方不单点，时间也不一致；

可以利用服务器的单点做序列化。

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

sender1发出msg1，sender2发出msg2；

msg1和msg2经过接入集群，服务集群；

service层到底层拿一个唯一seq，来确定接收方展示时序；

service拿到msg2的seq是20，msg1的seq是30；

通过投递服务讲消息给多个群友，群友即使接收到msg1和msg2的时间不同，但可以统一按照seq来展现。

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

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