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

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

• 疯狂创客圈 经典图书 ： 《Netty Zookeeper Redis 高并发实战》 面试必备 + 大厂必备 + 涨薪必备
• 疯狂创客圈 经典图书 ： 《SpringCloud、Nginx高并发核心编程》 面试必备 + 大厂必备 + 涨薪必备
• 资源宝库： Java程序员必备 网盘资源大集合 价值>1000元 随便取 GO->【博客园总入口 】
• 抢书活动：联合机械工业出版社 Java高并发三部曲 150本纸质书大赠送，手快有，手慢无 ->【博客园总入口 】
• 独孤九剑：Netty灵魂实验 ： 本地 100W连接 高并发实验，瞬间提升Java内力
• 最纯粹的技术交流：和大厂 小伙伴、技术高手、架构师 进行 纯粹的的技术问题交流、探讨求助、问题围观学习

---

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

高并发 必读 的精彩博文
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），这三种报文的解释如下：

R：客户端主动发送给服务器的报文
A：服务器被动应答客户端的报文，一个A对应一个R
N：服务器主动发送给客户端的报文

二、普通消息投递流程

用户A给用户B发送一个“你好”，流程如下：

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给一个消息的确认，这个应用层的确认的流程，与消息的发送流程类似：

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，以定时重发。

一旦收到了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