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》。

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、全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

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

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

引用：JackJiang 发表于 2016-05-10 13:44
这篇文章对IM的消息送达保证机制讲的比较清楚，实用性也比较强，暂未了解过相关机制的群友值得看看。
Mobi ...

有群聊的实现思路吗？群聊要保证到达的话，成本比较大啊。
我之前看过，微信是把群聊分发后，当成个人聊天一样的处理的。这种方式成本很大，1000人的群就扩散了1000次。而且一旦要保证到达，离线消息的保存成本也很大。
所以请教一下，如果群聊也要保证到达，有无比较优化的思路？

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

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

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

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

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

引用：JackJiang 发表于 2016-05-10 15:13
我认为群消息和个人消息，其实以现在的移动端体验来说，应该是没有区别的，所以你不应该从思维里就把群消 ...

你说的跟微信的设计是一致的，把群消息当个人消息处理。
而2个问题我在实际中确实遇到了。
第1个还好解决，通过消息id来排序；
第2个就很麻烦了，群消息对服务器压力实在太大。个人消息，1s顶多两三条消息，而群消息，1s峰值可能达到上百条消息，而且要扩散处理，一下子就指数级暴涨。
对于这一点，请问大大有没有比较好的解决思路，或者应该用什么算法？

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

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

引用：JackJiang 发表于 2016-05-11 11:23
第2点，要想完美肯定只能集群来解决，不然没有伸缩性，单机的话怎么优化总归是要到终点的，而且不能出现 ...

我们还没正式推出使用，现在还是内部运用。
峰值的问题，是我用机器人压测的时候出现的。我用的vm虚拟机，个人聊天可以达到2k人没问题。群聊300左右就到达峰值了。后面我就用了任务队列，牺牲用户体验了，每个人发消息都要排队，超时就发送失败。

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

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

收藏先·

学习了，楼主牛逼

收藏收藏

学习了

收藏学习啦

讲解的非常清楚，对于个人对个人很清楚，去重机制good

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

这个可以利用共享模式，对于这种情况只分配一个单元就可以了，减少内存的分配

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

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

引用：JackJiang 发表于 2017-08-02 11:03
你说的还是比较笼统，可以具体的说说

1000个人的群，对于一个群发，就是一条消息被发了1000次，而我们离线存储肯定就存储这一条消息啊，这条消息不但有消息的内容，消息的时间，还会有超时时间。。。这是我的方案

A端是否重发不应该依赖B端的ack，A把消息成功上报给服务器就应该认为消息投递成功，至于消息是否真的发给了B，以及消息的超时重试机制，应该由后端保障。我觉得这样比较好一些。B端的网络状况的好坏，不应该影响到A用户的感知，否则用户体验会比较差。

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

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

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

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

我们公司现在的消息必达是这么设计的，不需要6步那么复杂，只有Msg:R, Msg:A,MsgN。
上半场：
客户端cl_A发送Msg:R,服务端收到后回Msg:A，此时客户端cl_A认为消息已经送达，但是提示未读。
下半场：
服务端发送Msg:N给cl_B，无论是否送达cl_B都不给服务端回ack，而服务端认为消息是已经到达cl_B。

那下半场怎么保证消息必达呢？用客户端上线同步。
如果服务点Msg:N在发送给cl_B的过程中丢失，那么cl_B一定不在线或者网络有问题，因此如果cl_B再次上线就会向服务端拉取离线期间有没有新的消息，来保证消息不会丢失。

总体看来这种方法，大大简化了消息流程，不用超时不用队列，各位大神看看这种设计有何问题？@JackJiang@JackJiang