《即时消息技术剖析与实战》学习笔记4——IM系统如何保证消息的可靠性

IM 系统中,保证消息的可靠投递主要体现在两方面,一是消息的不丢失,二是消息的不重复。

一、消息不丢失

消息丢失的原因

首先看一下发送消息的流程,如下图所示:
《即时消息技术剖析与实战》学习笔记4——IM系统如何保证消息的可靠性_第1张图片

图片来源于《即时消息技术剖析与实战》第 04 讲

用户 A 发出的消息,先到达IM服务端(步骤1),由服务端暂存(步骤2),成功后,服务端将成功的结果返回给用户A(步骤3),同时将消息推送给用户B(步骤4)。
在这个过程中,丢失消息有以下几种情况:
1)步骤 1 因为网络不通等原因导致用户A把消息发送到IM服务器失败;
2)步骤 2 IM服务器存储消息失败;
3)步骤 3 用户A在超时时间内未收到IM服务器返回的结果;
4)步骤 4 由于IM服务器断电等原因导致消息未能成功推送给用户B(但步骤 3 用户A可以收到IM服务器返回的响应成功结果);
5)步骤 4 消息成功推送给用户B的设备,但用户B的设备因为一些原因如设备写入本地DB失败等,也会导致消息丢失。
前三种情况,用户A将被提示消息发送失败;后两种情况,用户B未收到消息。

消息丢失的解决方案

大部分场景中,业务层ACK确认机制 + 消息重传机制 + 消息完整性检查,能解决消息丢失的问题。
1.业务层的ACK确认机制和重传机制

ACK是确认字符(Acknowledge character)的意思,TCP协议默认提供了ACK机制,如果接收方成功接收到数据,就会回复一个ACK数据,表示发送方发出的数据已确认接收无误,在“三次握手”、“四次挥手”中经常见到。
ACK确认机制:TCP传输时将每个字节的数据都进行编号,即序列号。TCP传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答,也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。有了序列号能够将接收到的数据根据序列号排序,并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。
重传机制:发送方发送一部分数据后,都会等待接收方发送的ACK报文,并解析ACK报文,判断数据是否传输成功。发送方迟迟收不到ACK报文的原因可能有两个:
1)数据在传输过程中由于网络原因等直接全体丢包,接收方没有接收到;
2)接收方接收到了响应的数据,但是发送的ACK报文响应却由于网络原因丢包了。
超时重传机制就是发送方在发送完数据后等待一个时间,如果在超时时间内没有接收到ACK报文,就重新发送数据。如果是上述的第一个原因,接收方收到二次重发的数据后,便进行ACK应答。如果是第二个原因,接收方发现接收的数据已存在,就直接丢弃,仍旧发送ACK应答。

业务层的ACK确认机制参考了TCP的ACK确认机制,其策略是IM服务器在推送消息时,携带一个标识SID(安全标识符,类似TCP的sequenceId),推送出消息后会将当前消息添加到“待ACK消息列表”,客户端B成功接收完消息后,会给IM服务器回一个业务层的ACK包,包中携带有本条接收消息的SID,IM服务器接收后,会从“待ACK消息列表”记录中删除此条消息,本次推送才算真正结束。

业务层的消息重传机制也参考了TCP协议的重传机制,IM服务器的“等待ACK队列”一般会维护一个超时计时器,一定时间内如果没有收到用户B发回的ACK包,就从“等待ACK队列”中重新拉取并进行重推。

为什么有了TCP协议本身的ACK机制,还需要业务层的ACK机制?
这是因为TCP属于传输层,而IM服务属于应用层。TCP的ACK保证网络传输层的可靠性,即消息是否送达,但不能保证数据能够被应用层正确可靠处理;业务层ACK进行消息是否送达和是否正确处理的逻辑,达到不丢消息、消息不重复的目的。

2.时间戳比对检查消息完整性
在上面列举的丢失消息的第 4 种可能性中,如果步骤 4 IM服务器将消息推送出去后就宕机了,而这条消息又因为某些原因丢失了,服务器由于宕机无法触发重传机制,导致用户B收不到该消息。可以采取“时间戳比对”机制进行完整性检查。
《即时消息技术剖析与实战》学习笔记4——IM系统如何保证消息的可靠性_第2张图片

图片来源于《即时消息技术剖析与实战》第 04 讲

时间戳比对过程如下:
1)IM服务器给用户B推送msg1,同时带上一个最新时间戳timestamp1。用户B收到msg1后,更新本地的时间戳为timestamp1;
2)IM服务器给用户B推送msg2,同时带上一个最新时间戳timestamp2。由于某种原因,用户B和IM服务器的连接断开,导致msg2没有成功推送到用户B;
3)用户B和IM服务器重新建立连接后,将本地的时间戳timestamp1发送给IM服务器,IM服务器将时间戳大于timestamp1的所有消息全部发送给用户B,同时带上时间戳timestamp2(这里假设时间戳大于timestamp1的消息只有msg2,如果有msg3、msg4等多条消息,应取最新消息的时间戳);
4)用户B收到msg2后,更新本地的时间戳为timestamp2。
通过这样的比对可以有效解决消息丢失的问题。但时间戳由于有时钟不同步、或者一个时间戳内多条消息的可能性,存在误差,因此可以使用全局的自增序列版本号来代替。

二、消息不重复

消息重复的原因

在上面列举的丢失消息的几种可能性中,第 3 种可能性存在一种场景,步骤 4 将消息成功推送给用户B,但步骤 3 因为某些原因导致超时、用户A收不到响应,这个时候会触发重传机制,用户A重新发送请求,用户B可能会收到重复消息。

消息重复的解决方案

IM服务器推送消息时,携带一个Sequence ID,这个Sequence ID在本次连接会话中唯一,同时针对同一条消息不变。当接收方接收到消息后,会根据这个Sequence ID来进行业务层的去重,可以有效地保证消息的不重复。

三、小结

通过业务层的ACK机制、重传机制和完整性检查,可以有效解决推送过程中消息丢失的问题;
通过客户端的去重机制,可以有效解决消息重复的问题。

你可能感兴趣的:(《即时消息技术剖析与实战》学习笔记4——IM系统如何保证消息的可靠性)