IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

1、前言

互联网发展至今，IM（即时通讯聊天应用）一直是互联网上最为成功也是最为平常的应用类型。尤其现今的移动互联网时代，因即时通讯技术的发展和普及，IM这种即时通讯应用已乎达成了各即时通讯应用运营者梦寐已求的所谓“全时在线”，而这种“全时在线”及其应用体验的背后，回归到技术本质就是各种行为消息（或者说信息）的实时性、必达性。

本文将要讨论的是即时IM应用中极其重要但也不被用户感知的消息送达保证机制（即QoS机制），文中将给出目前主流的参考实现思路。

另外，开源轻量级移动端即时通讯框架 MobileIMSDK 的消息送达保证（QoS机制）的大致原理请见：http://www.52im.net/thread-129-1-2.html，3楼Jack Jiang的回复已指出技术原理，跟本文中所描术的思路异曲同工，需要的可以看看。也可以从《为什么说基于TCP的移动端IM仍然需要心跳保活？》一文中了解到TCP协议下的移动端IM网络状况分析。

2、IM开发干货系列文章

本文是系列文章中的第1篇，总目录如下：

• 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》（本文）
• 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
• 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
• 《移动端IM登录时拉取数据如何作到省流量？》
• 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
• 《浅谈移动端IM的多点登陆和消息漫游原理》
• 《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
• 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
• 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
• 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
• 《IM群聊消息的已读回执功能该怎么实现？》
• 《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
• 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
• 《一个低成本确保IM消息时序的方法探讨》
• 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
• 《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
• 《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
• 《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
• 《IM的扫码登功能如何实现？一文搞懂主流应用的扫码登陆技术原理》
• 《IM要做手机扫码登陆？先看看微信的扫码登录功能技术原理》
• 《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
• 《IM开发实战干货：我是如何解决大量离线聊天消息导致客户端卡顿的》
• 《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
  

另外，如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

3、本文概述

消息的可靠性，即消息的不丢失和不重复，是IM系统中的一个难点。当初QQ在技术上（当时叫OICQ）因为以下两点原因才打败了ICQ：

• QQ的消息投递可靠（消息不丢失，不重复）；
• QQ的垃圾消息少（它antispam做得好，这也是一个难点，但不是本文重点讨论的内容）。
  

今天，本文将用十分通俗的语言，来讲述IM系统中消息可靠性的问题。

4、报文类型

IM的客户端与服务器通过发送报文（也就是请求包）来完成消息的传递。

报文分为三种：

• 请求报文（request，后简称为为R）；
• 应答报文（acknowledge，后简称为A）；
• 通知报文（notify，后简称为N）。
  

这三种报文的解释如下：

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

5、普通消息投递流程

用户A给用户B发送一个“你好”，很容易想到，流程如下：

• client-A向im-server发送一个消息请求包，即msg:R
• im-server在成功处理后，回复client-A一个消息响应包，即msg:A
• 如果此时client-B在线，则im-server主动向client-B发送一个消息通知包，即msg:N（当然，如果client-B不在线，则消息会存储离线）
  

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

从流程图中容易看到，发送方client-A收到msg:A后，只能说明im-server成功接收到了消息，并不能说明client-B接收到了消息。在若干场景下，可能出现msg:N包丢失，且发送方client-A完全不知道，例如：

• 服务器崩溃，msg:N包未发出
• 网络抖动，msg:N包被网络设备丢弃
• client-B崩溃，msg:N包未接收
  

结论是悲观的：接收方client-B是否有收到msg:N，发送方client-A完全不可控，那怎么办呢？

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

我们来参考网络传输协议的实现：UDP是一种不可靠的传输层协议，TCP是一种可靠的传输层协议，TCP是如何做到可靠的？答案是：超时、重传、确认。（即时通讯网注：实际上IM中，数据通讯层无论用的是UDP还是TCP协议，都同样需要消息送达保证（即QoS）机制，原因在于IM的通信是A端-Server-B端的3方通信，而非传统C/S或B/S这种2方通信）。

要想实现应用层的消息可靠投递，必须加入应用层的确认机制，即：要想让发送方client-A确保接收方client-B收到了消息，必须让接收方client-B给一个消息的确认，这个应用层的确认的流程，与消息的发送流程类似：

• client-B向im-server发送一个ack请求包，即ack:R
• im-server在成功处理后，回复client-B一个ack响应包，即ack:A
• 则im-server主动向client-A发送一个ack通知包，即ack:N
  

至此，发送“你好”的client-A，在收到了ack:N报文后，才能确认client-B真正接收到了“你好”。

你会发现，一条消息的发送，分别包含（上）（下）两个半场，即msg的R/A/N三个报文，ack的R/A/N三个报文。一个应用层即时通讯消息的可靠投递，共涉及6个报文，这就是im系统中消息投递的最核心技术（如果某个im系统不包含这6个报文，不要谈什么消息的可靠性）。

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

期望六个报文完成消息的可靠投递，但实际情况下：

• msg:R，msg:A 报文可能丢失：
  此时直接提示“发送失败”即可，问题不大；
• msg:N，ack:R，ack:A，ack:N这四个报文都可能丢失：
  （原因如第二章所述，可能是服务器奔溃、网络抖动、或者客户端奔溃），此时client-A都收不到期待的ack:N报文，即client-A不能确认client-B是否收到“你好”。
  

那怎么办呢？

9、消息的超时与重传

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队列”中移除。

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

第五节提到过，msg:N报文，ack:N报文都有可能丢失：

• msg:N 报文丢失：说明client-B之前压根没有收到“你好”报文，超时与重传机制十分有效
• ack:N 报文丢失：说明client-B之前已经收到了“你好”报文（只是client-A不知道而已），超时与重传机制将导致client-B收到重复的消息。
  

启示：

平时使用qq，或许大伙都有类似的体验，弹出一个对话框“因为网络原因，消息发送失败，是否要重发”，此时，有可能是对方没有收到消息（发送方网络不好，msg:N丢失），也可能已经收到了消息（接收方网络不好，反复重传后，ack:N依然丢失），出现这个提示时，大伙不妨和对端确认一下，看是哪种情况。

11、消息的去重

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

12、其他

1）上述设计理念，由客户端重传，可以保证服务端无状态性（架构设计基本准则）；
2）如果client-B不在线，im-server保存了离线消息后，要伪造ack:N发送给client-A；
3）离线消息的拉取，为了保证消息的可靠性，也需要有ack机制，但由于拉取离线消息不存在N报文，故实际情况要简单的多，即先发送offline:R报文拉取消息，收到offline:A后，再发送offlineack:R删除离线消息。

13、总结

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

个人消息是一个1对1的ack，群消息就没有这么简单了，群消息存在一个扩散系数，im群消息的可靠投递问题感兴趣的可查阅相关资料。

14、更多IM开发综合文章

《新手入门一篇就够：从零开发移动端IM》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《小白必读：闲话HTTP短连接中的Session和Token》
《IM开发基础知识补课：正确理解前置HTTP SSO单点登录接口的原理》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《一个低成本确保IM消息时序的方法探讨》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《谈谈移动端 IM 开发中登录请求的优化》
《移动端IM登录时拉取数据如何作到省流量？》
《浅谈移动端IM的多点登录和消息漫游原理》
《完全自已开发的IM该如何设计“失败重试”机制？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移动端主流图片格式的特点、性能、调优等》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
《融云技术分享：解密融云IM产品的聊天消息ID生成策略》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》
《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》
《适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)》
《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《IM要做手机扫码登录？先看看微信的扫码登录功能技术原理》
《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》
《零基础IM开发入门(一)：什么是IM系统？》
《零基础IM开发入门(二)：什么是IM系统的实时性？》
《零基础IM开发入门(三)：什么是IM系统的可靠性？》
《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》
《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
《IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《IM扫码登录技术专题(一)：微信的扫码登录功能技术原理调试分析》
《IM扫码登录技术专题(二)：市面主流的扫码登录技术原理调试分析》
《IM扫码登录技术专题(三)：通俗易懂，IM扫码登录功能详细原理一篇就够》
《IM扫码登录技术专题(四)：你真的了解二维码吗？刨根问底、一文掌握！》
《理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨》
《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
《IM开发干货分享：万字长文，详解IM“消息“列表卡顿优化实践》
《IM全文检索技术专题(三)：网易云信Web端IM的聊天消息全文检索技术实践》
《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践》
《探探的IM长连接技术实践：技术选型、架构设计、性能优化》
《IM开发干货分享：浅谈IM系统中离线消息、历史消息的最佳实践》
>> 更多同类文章 ……

（原文链接：http://www.habadog.com/2015/04/29/webim-msg-send-ack/）

这篇文章对IM的消息送达保证机制讲的比较清楚，实用性也比较强，暂未了解过相关机制的群友值得看看。
MobileIMSDK的消息送达机制，跟文中的思路几乎是一致的，可以对照源码参考一下哦。

引用：kezhaoyuan 发表于 2016-05-10 14:31
有群聊的实现思路吗？群聊要保证到达的话，成本比较大啊。
我之前看过，微信是把群聊分发后，当成个人聊 ...

我认为群消息和个人消息，其实以现在的移动端体验来说，应该是没有区别的，所以你不应该从思维里就把群消息当2等公民，从而在方案的设计上出现问题。

回归到事情本质，现在移动端IM（比如微信）对于群消息的定义，就相当于是一条同时发给群里所有人的聊天消息，所以在构思方案时就把它当成一条普通的聊天消息，这样从数据结构和基本的模型上来说，就不用复杂化了。那么余下的事情，就只需要专心解决2个问题：
1）群消息下发的即时性：这是个难点，因为当你用多线程或其它并发异步机制同时发送时对于不同的接收人而言可能产生乱序（此一条还没发完下一条消息又要已在发送），在乱序与实时性问题上性能处理就很可能是悖论；
2）群消息下发时的服务端瞬时负载问题。

除此之外，它跟普通消息可以用同样的模型，就简单一点。

以上是个人意见，仅供参考。

引用：kezhaoyuan 发表于 2016-05-11 11:17
你说的跟微信的设计是一致的，把群消息当个人消息处理。
而2个问题我在实际中确实遇到了。
第1个还好解 ...

第2点，要想完美肯定只能集群来解决，不然没有伸缩性，单机的话怎么优化总归是要到终点的，而且不能出现峰值，一旦出现峰值，单机很快就雪崩了。你们的用户量应该是越来越大了吧，单机终归不是最终解决方案，要自已做好IM，只能持续不断优化架构和设计。

引用：kezhaoyuan 发表于 2016-05-12 18:49
我们还没正式推出使用，现在还是内部运用。
峰值的问题，是我用机器人压测的时候出现的。我用的vm虚拟机 ...

先把单机性能优化到极致，然后果断考虑集群吧

引用：zjjishitongxun 发表于 2017-08-02 10:20
这个可以利用共享模式，对于这种情况只分配一个单元就可以了，减少内存的分配

你说的还是比较笼统，可以具体的说说

引用：researchboy 发表于 2017-09-25 21:21
A端是否重发不应该依赖B端的ack，A把消息成功上报给服务器就应该认为消息投递成功，至于消息是否真的发给了 ...

你的理解其实也是方案的一种，但一个现实情况是：
在高并发的场景下有些逻辑能放到客户端做的就尽量别放到服务端做，因为一个客户端面对的正在聊天中的好友数了不起几十人吧（我说的是正在聊天中的，离线或静默的好友不在此列），这样的计算或资源占用没什么大不了。

但服务端对于动辄10万、百万的同时在线的情况下，多出任何一个业务和处理逻辑那动用的服务端资源都是非常可观的，你把上面的有些可以放到服务端的逻辑试着想想，假如现在放到服务端去实现该面临什么情况呢？

如果你是服务端开发者，你所面对的如此大的并发压力的情况下，你会怎么去做呢？

引用：x931609201 发表于 2017-11-17 11:11
我们公司现在的消息必达是这么设计的，不需要6步那么复杂，只有Msg:R, Msg:A,MsgN。
上半场：
客户端cl_A ...

你的设计，理论上可以这样做。但有一个前提，那就是你用的协议一定是TCP的，因为如果是UDP的话，MsgN被服务端送出，到底cl_B有没有被收到，其实服务端是不知道的，这UDP协议的先天特性，无法改变。

MobileIMSDK用的是UDP协议，用的是4步，而且不管是从算法还是逻辑是都非常简单易懂，比你的TCP这个流程多了一步，有兴趣的话可以去看看。

引用：ym_im 发表于 2018-01-11 18:16
可不可以只要四步 客户端 A MSG:R 服务器收到后，服务器发送msg到cl_B,
cl_b ack 给 服务器， 服务器ack响 ...

可以，MobileIMSDK框架就是这么干的。

引用：zgy5352 发表于 2018-05-23 17:08
ios客户端发一条消息 怎么判断这条消息已经成功发送给服务端了  
- (int) sendCommonDataWithStrNSStrin ...

MobileIMSDK中，对方收到的消息，会通过MessageQoSEvent中的回调方法：- (void) messagesBeReceived: 告诉你。

引用：zgy5352 发表于 2018-05-23 17:37
如果对方在线确实会走 messagesBeReceived 这个回调,但是如果对方不在线,那个回调就不会走

不在线的话，服务端会走回离线处理 ServerEventListener. onTransBuffer_C2C_RealTimeSendFaild_CallBack()，你实现了服务端的离线处理后，服务端会代对方向你发送一个消息确认ACK，你就可以在iOS这里收到了，具体你看看onTransBuffer_C2C_RealTimeSendFaild_CallBack的文档说明（尤其是关于返回值的）。网络通信程序都是需要客户端和服务端配合成一个整体成实现的。

引用：zgy5352 发表于 2018-06-13 21:10
如果对方在线,QOS 的6个报文,第2个报文和第6个报文会同时回调吗

其实1、2、3、4就够了，5和6可以省去。做im并不是做金融系统，没有必要也很难保证理论上的百分之百，qq和微信的设计原则同样遵循万有一失这个原则。

引用：lmyJavaDE1 发表于 2018-09-03 13:49
请问 这张图的第二步的包如果丢了 客户端怎么判断丢了，是不是也是定时判断？
第六步的包丢了，客户端定 ...

你只要记住一个原则：只要发送方没有收到接收方的应答，它就可以认为消息没达送，不管中间有多少环节。

至于重传间隔，这是个经验值，你需要在你的IM用户能容忍多长的消息延迟（重传消息对于用户来说，就是延迟的消息）、和服务端的性能负载上来决定，比如3秒、5秒。。，时间如果太长的话，那就不叫即时通讯了，影响体验

引用：cron 发表于 2018-11-30 15:25
您好，关于9，消息的超时与重传，有几个问题，想请教一下。维护的等待ack队列，是从接收方维度来分的吗。比 ...

ACK重传算法机制是在客户端实现的，所以这不难。
服务端的连接超时这些东西，如果你用java的netty或mina的话，它们都给你实现好了，不需要你自已这样野蛮地实现了

引用：cron_vQ07C 发表于 2018-12-03 10:55
谢谢您的回复，我想再问下具体的。因为我用的就是netty，我关于每个连接用户，是启动这个定时任务的，
  ...

你这代码是客户端的还是服务端的？

引用：cron_vQ07C 发表于 2018-12-03 14:12
我是服务端的，我刚在做的是一个推送系统。给所有在线的用户（app）推个消息，现在加入了重试机制。我想 ...

你如果是做推送系统，服务端可以单独起一个线程，检查未收到ack的包队列。

引用：110766457 发表于 2019-01-22 13:30
你好，我想说一下自己的看法。
我觉得重发应该放在服务端而不是客户端。如果重发逻辑在客户端，会有这样 ...

你说的第1种情况：如果此时B的网络确实差，对于服务端而言，就会判定对方离线，此时走离线消息逻辑就可以了，而A这边会收到服务端的伪应符包——对于A的体验是，消息还是送出了，只是不知道对方是不是实时收到了还是存入离线了而已；

第2种情况：确实存在这样的问题，但这是非常极端的情况下，而且一般的算法，在app挂起时，重传逻辑也挂起了，下次打开时还会重新开始。但，如果app被系统杀掉了就没招了。

但做法没有一个固定的套路，这也是im为什么不好写的原因，因为不标准，一百个人有一百个实现方法。能解决自已的问题就行了，不用太过纠结

引用：hujisha 发表于 2019-03-02 10:25
不是很理解，既然tcp已经提供了确认机制，为什么应用层还要再加一个呢？

你需要读一下这篇文章：《为什么说基于TCP的移动端IM仍然需要心跳保活？》

引用：lijingpei2016 发表于 2019-04-10 14:28
群主好，请问在A和B都同时在线的时候，又不用做“已读”功能
是否可以简化为这样？

如果你读过我写的 MobileIMSDK的源码，就可以知道，我认为：应答应该由B来告诉A，而不是由服务器，这样最精简，也最精确，因为收没收到B的应答是最精准的

引用：yangyang 发表于 2020-09-25 15:17
源码3.0中没有处理粘包的情况吗，我只看到直接一堆发出去了，没有包头吗

你指的源码，具体指的是哪个工程？