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的消息送达机制，跟文中的思路几乎是一致的，可以对照源码参考一下哦。

引用：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