IM的消息,如何保障可靠性

文章很长,建议收藏起来,慢慢读! 疯狂创客圈为小伙伴奉上以下珍贵的学习资源:


推荐: 疯狂创客圈 高质量 博文

高并发 必读 的精彩博文
nacos 实战(史上最全) sentinel (史上最全+入门教程)
Zookeeper 分布式锁 (图解+秒懂+史上最全) Webflux(史上最全)
SpringCloud gateway (史上最全) TCP/IP(图解+秒懂+史上最全)
10分钟看懂, Java NIO 底层原理 Feign原理 (图解)
更多精彩博文 ..... 请参见【 疯狂创客圈 高并发 总目录

IM的消息,如何保障可靠性

IM App 是我做过 App 类型里复杂度最高的一类,里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下消息可靠抵达机制。

如何确保 IM 不丢消息是个相对复杂的话题,从客户端发送数据到服务器,再从服务器抵达目标客户端,最终在 UI 成功展示,其间涉及的环节很多,这里只取其中一环「接收端如何确保消息不丢失」来探讨,粗略聊下我接触过的两种设计思路。

说到可靠抵达,第一反应会联想到 TCP 的 reliability。数据可靠抵达是个通用性的问题,无论是网络二进制流数据,还是上层的业务数据,都有可靠性保障问题,TCP 作为网络基础设施协议,其可靠性设计的可靠性是毋庸置疑的,我们就从 TCP 的可靠性说起。

在 TCP 这一层,所有 Sender 发送的数据,每一个 byte 都有标号(Sequence Number),每个 byte 在抵达接收端之后都会被接收端返回一个确认信息(Ack Number), 二者关系为 Ack = Seq + 1。简单来说,如果 Sender 发送一个 Seq = 1,长度为 100 bytes 的包,那么 receiver 会返回一个 Ack = 101 的包,如果 Sender 收到了这个Ack 包,说明数据确实被 Receiver 收到了,否则 Sender 会采取某种策略重发上面的包。

第一个问题是:现在的 IM App 几乎都是走 TCP 通道,既然 TCP 本身是具备可靠性的,为什么还会出现消息接收端(Receiver)丢失消息的情况,看下图一目了然:

在这里插入图片描述

一句话总结上图的含义:网络层的可靠性不等同于业务层的可靠性

数据可靠抵达网络层之后,还需要一层层往上移交处理,可能的处理有:安全性校验,binary 解析,model 创建,写 db,存入 cache,UI 展示,以及一些 edge cases(断网,用户 logout,disk full,OOM,crash,关机。。) 等等,项目的 feature 越多,网络层往上的处理出错的可能性就越大。

举个最简单的场景为例子,消息可靠抵达网络层之后,写 db 之前 App crash(不稀奇,是 App 都会 crash),虽然数据在网络层可靠抵达了,但没存进 db,下次用户打开 App 消息自然就丢失了,如果不在业务层再增加可靠性保障,网络层面不会重发,那么意味着这条消息对于 Receiver 永远丢失了。业务层保障可以采取两种方案:


简单的方案:应用层 Ack 消息

这个方案可以简单理解为,将 TCP 的 Ack 流程再走一遍,在应用层也构建一个 Ack 消息,在应用层可靠性得到确认之后,再发送这个 Ack 消息。

发送端收到接收端Ack 消息之后,才认为 接收端 已收到,否则也采取某种策略重发消息(一个重发队列,进行timer定时扫描)。

具体实现:

一、报文类型

im的客户端与服务器通过发送报文(也就是网络包)来完成消息的传递,报文分为三种

请求报文(request,后简称为为R)

应答报文(acknowledge,后简称为A)

通知报文(notify,后简称为N),这三种报文的解释如下:
img
R:客户端主动发送给服务器的报文
A:服务器被动应答客户端的报文,一个A对应一个R
N:服务器主动发送给客户端的报文

二、普通消息投递流程

用户A给用户B发送一个“你好”,流程如下:
img
1)client-A向im-server发送一个消息请求包,即msg:R
2)im-server在成功处理后,回复client-A一个消息响应包,即msg:A
3)如果此时client-B在线,则im-server主动向client-B发送一个消息通知包,即msg:N(当然,如果client-B不在线,则消息会存储离线)

三、上述消息投递流程出现的问题

从流程图中容易看到,发送方client-A收到msg:A后,只能说明im-server成功接收到了消息,并不能说明client-B接收到了消息。在若干场景下,可能出现msg:N包丢失,且发送方client-A完全不知道,例如:
1)服务器崩溃,msg:N包未发出
2)网络抖动,msg:N包被网络设备丢弃
3)client-B崩溃,msg:N包未接收
结论是悲观的:接收方client-B是否有收到msg:N,发送方client-A完全不可控,那怎么办呢?

四、应用层确认+im消息可靠投递的六个报文

upd是一种不可靠的传输层协议,tcp是一种可靠的传输层协议,tcp是如何做到可靠的?答案是:超时、重传、确认。
要想实现应用层的消息可靠投递,必须加入应用层的确认机制,即:要想让发送方client-A确保接收方client-B收到了消息,必须让接收方client-B给一个消息的确认,这个应用层的确认的流程,与消息的发送流程类似:
img
4)client-B向im-server发送一个ack请求包,即ack:R
5)im-server在成功处理后,回复client-B一个ack响应包,即ack:A
6)则im-server主动向client-A发送一个ack通知包,即ack:N
至此,发送“你好”的client-A,在收到了ack:N报文后,才能确认client-B真正接收到了“你好”。
会发现,一条消息的发送,分别包含(上)(下)两个半场,即msg的R/A/N三个报文,ack的R/A/N三个报文,一个应用层即时通讯消息的可靠投递,共涉及6个报文,这就是im系统中消息投递的最核心技术。

五、可靠消息投递存在什么问题

期望六个报文完成消息的可靠投递,但实际情况,msg:N,ack:N这两个报文都可能丢失(原因如第二点所述,可能是服务器奔溃、网络抖动、或者客户端奔溃),此时client-A都收不到期待的ack:N报文,即client-A不能确认client-B是否收到“你好”,但这两个报文的丢失对应的业务影响又大有不同:

1)msg:N包丢失,业务结果是client-B没有收到消息

2)ack:N包丢失,业务结果是client-B收到了消息,只是client-A不知道而已

那怎么办呢?

六、消息的超时与重传

client-A发出了msg:R,收到了msg:A之后,在一个期待的时间内,如果没有收到ack:N,client-A会尝试将msg:R重发。可能client-A同时发出了很多消息,故client-A需要在本地维护一个等待ack队列,并配合timer超时机制,来记录哪些消息没有收到ack:N,以定时重发。
img
一旦收到了ack:N,说明client-B收到了“你好”消息,对应的消息将从“等待ack队列”中移除。

七、消息的重传存在什么问题

第五点提到过,msg:N,ack:N都有可能丢失:
1)msg:N报文丢失,说明client-B之前压根没有收到“你好”报文,超时与重传机制十分有效
2)ack:N报文丢失,说明client-B之前已经收到了“你好”报文(只是client-A不知道而已),超时与重传机制将导致client-B收到重复的消息,那怎么办呢?

八、消息的去重

解决方法也很简单,由发送方client-A生成一个消息去重的msgid,保存在“等待ack队列”里,同一条消息使用相同的msgid来重传,供client-B去重,而不影响用户体验。

九、其他

1)上述设计理念,由客户端重传,可以保证服务端无状态性(架构设计基本准则)
2)如果client-B不在线,im-server保存了离线消息后,要伪造ack:N发送给client-A

十、总结

1)im系统是通过超时、重传、确认、去重的机制来保证消息的可靠投递,不丢不重
2)一个“你好”的发送,包含上半场msg:R/A/N与下半场ack:R/A/N的6个报文

3)im系统难以做到系统层面的不丢不重,只能做到业务层面的不丢不重

参考文章:

https://blog.csdn.net/wufaliang003/article/details/78638364

https://www.jianshu.com/p/4781cf9ffce8

posted @ 2021-04-15 16:39  疯狂创客圈  阅读(156)  评论(0编辑  收藏  举报