Home / 龙笛即时通讯 / 龙笛特色 / 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

IM App 是我做过 App 类型里复杂度最高的一类,里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制(因为我个人对移动客户端的经验积累的比较丰富嘛)。

TCP协议的可靠性之外还会出现消息丢失?

如何确保 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 永远丢失了。

客户端方案1:应用层 Ack 消息

这个方案可以简单理解为,将 TCP 的 Ack 流程再走一遍,在应用层也构建一个 Ack 消息,在应用层可靠性得到确认(一般以存入 db 为准,更准确说是事务提交成功的回调函数)之后再发送这个 Ack 消息,Server 收到应用层 Ack 消息之后才认为 Receiver 已收到,否则也采取某种策略重发消息。

具体到 IM App 当中,接收端接受到 Server 的 Message,将 Message 存入 db,在确认回调里发送 Ack Receive 消息,Server 收到 Ack Receive 即认为消息已经可靠抵达,否则会在某个时机重新推送(比如客户端重连服务器时候 Pull,比如有新消息时 Server Push)。

客户端方案2:应用层 Seq ID

这个方案和上面不同,但也是在应用层操作。我们个每个 Message 分配一个 Seq ID,这个 Seq ID 对于单个用户的接受消息队列来说是连续的,如果 Message A 和 Message B 是相邻的,那么 MsgBSeqID = MsgASeqID + 1。每次存入 db 的时候更新 db 里的 LastReceivedSeqID,LastReceivedSeqID 即为上一条写入数据库消息的 Seq ID。

这么做的好处是,每次从网络层收到消息时,从 db 里取出 LastReceivedSeqID,如果 LastReceivedSeqID = 新消息 Seq ID - 1,那么说明应用层消息时连续的没有发生丢失。还可以对收到的批量消息做预检测,检查消息队列里的 Seq ID 是否为联系的,只要存在任何一种不连续的 Seq ID 情况,就说明发送了丢失,此时接收端可以用 LastReceivedSeqID 从 Server 重新获取准确的接受消息队列。

这么做的好处是避免了每次都需要发送一条 Ack 消息,坏处是应用层逻辑复杂之后,一旦出现 Seq ID 不连续的情况,会过度依赖于 refetch,难以分析问题出现的原因,refetch 一旦过于频繁,其流量损耗极有可能大于 Ack 消息的数据量。

本文小结

消息的可靠抵达可以抽象为更一般意义上的可靠性问题,工程上总会碰到需要解决各种形式可靠性问题的场景,以经典计算机理论或者实践为基础来分析应用层的工程问题,可以举一反三,药到病除。

在工程上实践可靠性,需要线了解工程的每一个环节以及数据如何在各个环节流动,接下来才是分析每一个环节数据出错的可能性。检验可靠性的标准时「入袋为安」,存入 db 或者以其他方式持久化到 disk 当中,这样才能保证客户端每次都能正确读取到消息。

另外,可靠性可以理解为两方面:

· 一是数据可靠抵达(没有任何中间数据被丢失);

· 二是正确抵达(没有乱序或者数据更改)。

其实理论上 TCP 也不是 100% 可靠(数据有可能在传输时改变而无法被检测到),而是 100% 工程上可靠(数据改变而不被检测到时个极小概率的事件),这是另外一个有意思的话题。