IM群聊消息如此复杂，如何保证不丢不重？

1、前言

群聊已经成为主流IM软件的基本功能，不管是QQ群、还是微信群，一个群友在群内发了一条消息，那么对于IM服务器来说需要保证：

• 在线的群友能第一时间收到消息；
• 离线的群友能在登陆后收到消息。
  

由于“消息风暴扩散系数”的存在（概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》），群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。

2、IM开发干货系列文章

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

• 《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群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
• 《IM群聊消息的已读回执功能该怎么实现？》
• 《关于IM即时通讯群聊消息的乱序问题讨论》
• 《现代IM系统中聊天消息的同步和存储方案探讨》
• 《移动端IM中大规模群消息的推送如何保证效率、实时性？》
• 《微信后台团队：微信后台异步消息队列的优化升级实践分享》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
• 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
• 《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》
  

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

3、常见的群消息流程

开始讲群消息投递流程之前，先介绍两个群业务的核心数据结构：

群成员表：用来描述一个群里有多少成员
t_group_users(group_id, user_id)
群离线消息表：用来描述一个群成员的离线消息
t_offine_msgs(user_id, group_id, sender_id,time, msg_id, msg_detail)

业务场景举例：

• 1）一个群中有x,A,B,C,D共5个成员，成员x发了一个消息；
• 2）成员A与B在线，期望实时收到消息；
• 3）成员C与D离线，期望未来拉取到离线消息。
  

系统架构简介：

• 1）客户端：x,A,B,C,D共5个客户端用户；
• 2）服务端：
    2.1）所有模块与服务抽象为server；
    2.2）所有用户在线状态抽象存储在高可用cache里；
    2.3）所有数据信息，例如群成员、群离线消息抽象存储在db里。
  

典型群消息投递流程，如上图步骤1-4所述：

• 步骤1：群消息发送者x向server发出群消息；
• 步骤2：server去db中查询群中有多少用户(x,A,B,C,D)；
• 步骤3：server去cache中查询这些用户的在线状态；
• 步骤4：对于群中在线的用户A与B，群消息server进行实时推送；
• 步骤5：对于群中离线的用户C与D，群消息server进行离线存储。
  

典型的群离线消息拉取流程，如上图步骤1-3所述：

• 步骤1：离线消息拉取者C向server拉取群离线消息；
• 步骤2：server从db中拉取离线消息并返回群用户C；
• 步骤3：server从db中删除群用户C的群离线消息。
  

存在的问题：
上述流程是最容易想，也最容易理解的，存在的问题也最显而易见：对于同一份群消息的内容，多个离线用户存储了很多份。假设群中有200个用户离线，离线消息则冗余了200份，这极大的增加了数据库的存储压力。

4、群消息优化1：减少存储量

为了减少离线消息的冗余度，增加一个群消息表，用来存储所有群消息的内容，离线消息表只存储用户的群离线消息msg_id，就能大大的降低数据库的冗余存储量，思路如下。

群消息表：用来存储一个群中所有的消息内容
t_group_msgs(group_id, sender_id, time,msg_id, msg_detail)
群离线消息表：优化后只存储msg_id
t_offine_msgs(user_id, group_id, msg_id)

这样优化后，群在线消息发送就做了一些修改：

• 步骤3：每次发送在线群消息之前，要先存储群消息的内容；
• 步骤6：每次存储离线消息时，只存储msg_id，而不用为每个用户存储msg_detail。
  

拉取离线消息时也做了响应的修改：

• 步骤1：先拉取所有的离线消息msg_id；
• 步骤3：再根据msg_id拉取msg_detail；
• 步骤5：删除离线msg_id。
  

存在的问题（如同单对单消息的发送一样）：

• 1）在线消息的投递可能出现消息丢失，例如服务器重启，路由器丢包，客户端crash；
• 2）离线消息的拉取也可能出现消息丢失，原因同上。
  

需要和单对单消息的可靠投递一样，加入应用层的ACK，才能保证群消息一定到达。

5、群消息优化2：应用层ACK

应用层ACK优化后，群在线消息发送又发生了一些变化：

• 步骤3：在消息msg_detail存储到群消息表后，不管用户是否在线，都先将msg_id存储到离线消息表里；
• 步骤6：在线的用户A和B收到群消息后，需要增加一个应用层ACK，来标识消息到达；
• 步骤7：在线的用户A和B在应用层ACK后，将他们的离线消息msg_id删除掉。
  

对应到群离线消息的拉取也一样：

• 步骤1：先拉取msg_id；
• 步骤3：再拉取msg_detail；
• 步骤5：最后应用层ACK；
• 步骤6：server收到应用层ACK才能删除离线消息表里的msg_id。
  

存在的问题：

• 1）如果拉取了消息，却没来得及应用层ACK，会收到重复的消息么？
    答案是肯定的，不过可以在客户端去重，对于重复的msg_id，对用户不展现，从而不影响用户体验
• 2）对于离线的每一条消息，虽然只存储了msg_id，但是每个用户的每一条离线消息都将在数据库中保存一条记录，有没有办法减少离线消息的记录数呢？
  

6、群消息优化3：离线消息表

其实，对于一个群用户，在ta登出后的离线期间内，肯定是所有的群消息都没有收到的，完全不用对所有的每一条离线消息存储一个离线msg_id，而只需要存储最近一条拉取到的离线消息的time（或者msg_id），下次登录时拉取在那之后的所有群消息即可，而完全没有必要存储每个人未拉取到的离线消息msg_id。

群成员表：用来描述一个群里有多少成员，以及每个成员最后一条ack的群消息的msg_id（或者time）
t_group_users(group_id, user_id, last_ack_msg_id(last_ack_msg_time))
群消息表：用来存储一个群中所有的消息内容，不变
t_group_msgs(group_id, sender_id, time,msg_id, msg_detail)
群离线消息表：不再需要了

离线消息表优化后，群在线消息的投递流程：

• 步骤3：在消息msg_detail存储到群消息表后，不再需要操作离线消息表（优化前需要将msg_id插入离线消息表）；
• 步骤7：在线的用户A和B在应用层ACK后，将last_ack_msg_id更新即可（优化前需要将msg_id从离线消息表删除）。
  

群离线消息的拉取流程也类似：

• 步骤1：拉取离线消息；
• 步骤3：ACK离线消息；
• 步骤4：更新last_ack_msg_id。
  

存在的问题：
由于“消息风暴扩散系数”的存在，假设1个群有500个用户，“每条”群消息都会变为500个应用层ACK，将对服务器造成巨大的冲击，有没有办法减少ACK请求量呢？

7、群消息优化4：批量ACK

由于“消息风暴扩散系数”的存在，如果每条群消息都ACK，会给服务器造成巨大的冲击，为了减少ACK请求量，很容易想到的方法是批量ACK。

批量ACK的方式又有两种：

• 1）每收到N条群消息ACK一次，这样请求量就降低为原来的1/N了；
• 2）每隔时间间隔T进行一次群消息ACK，也能达到类似的效果。
  

新的问题：批量ACK有可能导致：还没有来得及ACK群消息，用户就退出了，这样下次登录会拉取到重复的离线消息。
解决方案：msg_id去重，不对用户展现，保证良好的用户体验。

还可能存在的问题：群离线消息过多：拉取过慢。
解决方案：分页拉取（按需拉取）,分页拉取的细节在《IM消息送达保证机制实现(下篇)：保证离线消息的可靠投递》一章中有详细叙述，此处不再展开。

8、本文小结

群消息还是非常有意思的，可达性、实时性、离线消息、消息风暴扩散等等等等，做个总结：

• 1）不管是群在线消息，还是群离线消息，应用层的ACK是可达性的保障；
• 2）群消息只存一份，不用为每个用户存储离线群msg_id，只需存储一个最近ack的群消息id/time；
• 3）为了减少消息风暴，可以批量ACK；
• 4）如果收到重复消息，需要msg_id去重，让用户无感知；
• 5）离线消息过多，可以分页拉取（按需拉取）优化。
  

（原文链接：点此进入）

这个系列文章不错，多谢群主分享过来

谢谢分享，思路很不错

受教了，感谢楼主

那么问题来了：在批量ACK的时候，如果server给client发消息就出现了丢失，那么server端是不是需要重发，这样的话又需要设置重发的触发条件，得在一段时间内判断在线用户是否需要重发。应对这样的场景有没有好的解决办法呢？

引用：不吃香蕉的猴子 发表于 2017-04-10 17:54
那么问题来了：在批量ACK的时候，如果server给client发消息就出现了丢失，那么server端是不是需要重发，这 ...

做im这种应用，尽全力保证消息送达是肯定需要的，但有的时候费了很大劲、可能要消耗很多的性能、增大很多复杂性才解决了某种极小几率才可能出现的情况，那么可以考虑放弃解决，腾讯的设计原则就是允许“万有一失”，而且im消息并非电商这种高价值数据，丢一两条消息并不会产生什么严重的后果，所以不需要太钻牛角尖。

引用：JackJiang 发表于 2017-04-10 19:44
做im这种应用，尽全力保证消息送达是肯定需要的，但有的时候费了很大劲、可能要消耗很多的性能、增大很多 ...

嗯嗯，您说的对，非常感谢。

干货，学习了
我有一个问题想请教一下：
在实际应用中群消息和单聊消息分别存在不同的表中好吗？会不会让业务更复杂了？
文章中是群消息业务单独存了一个表是为了举例子还是说您就是这么设计的呢？
还有，最后一条确认的消息ID存在群成员表里合适么？实际情况下一个人会拥有多个群，同一个用户有多条记录，是每一条记录的最后确认msg_id是相同的（不区分是哪个群），还是说每个群成员记录都只是存了这个用户在这个群的最后确认的msg_id，如果是前者，数据一样会有冗余，如果是后者，是否没有这个必要，所有群消息都存在一个表里，只要记录一个msg_id，拉去属于用户自己的未读msg就可以了吧，到了客户端再区分是哪个群的，不需要单独拉某个群的未读消息吧？
谢谢🙏

引用：。面向阳光. 发表于 2017-04-17 18:46
干货，学习了
我有一个问题想请教一下：
在实际应用中群消息和单聊消息分别存在不同的表中好吗？会不会让 ...

根据你的实际情况决定就行了，不需要纠结太多，先把逻辑实现能再考虑表数据量的问题，因为你的系统用户数是一定的，而每个用户的群数量也差不多可以估算的出来，意味着相关表的数据量也能大致估算，你再根据表数据量的情况决定如何提升查询性能即可，不需要拘泥于别人的设计。

引用：JackJiang 发表于 2017-04-18 09:38
根据你的实际情况决定就行了，不需要纠结太多，先把逻辑实现能再考虑表数据量的问题，因为你的系统用户数 ...

嗯，最近一直在学习IM相关的东西，技术细节看了很多了，但是到了系统设计的时候，太纠结了，想的太长远，就比较复杂了，适可而止又不太甘心，不是说20倍设计，3倍实现么。。。别人的设计也看了很多，但是一般都是大的架构，很多细节都不会讲或者不屑于讲，大学狗还没毕业，目前在实习，求大神指条明路。。。。

引用：。面向阳光. 发表于 2017-04-18 11:16
嗯，最近一直在学习IM相关的东西，技术细节看了很多了，但是到了系统设计的时候，太纠结了，想的太长远， ...

不要系统还没开始做，就把数据想成海量的情况，这是自已吓自已。
暂时的设计够用就行，保留设计的前瞻性和扩展性即可。

这个还是非常值得学习参考的

讲的很清楚 问题分析的很透彻 作为新人看懂了 多谢分享

引用：JackJiang 发表于 2017-04-18 11:25
不要系统还没开始做，就把数据想成海量的情况，这是自已吓自已。
暂时的设计够用就行，保留设计的前瞻性 ...

大神好，目前遇到一个坑，我用message_server接收所有的udp消息,push_server往客户端转发消息，messsage和push用rabbit解耦，但是目前的情况是内网测试没问题，服务一上公网，NAT就使得message可以收到消息，而push发出的消息被NAT拦截了。我不想通过客户端往push先发消息建立通道的方式来解决。而都是用message又会让message变得很重，而且还难以横向拓展。有没有关于udp做消息服务的好的建议和设计思路。message使用netty作为网络层通信框架。

引用：不吃香蕉的猴子 发表于 2017-05-10 13:17
大神好，目前遇到一个坑，我用message_server接收所有的udp消息,push_server往客户端转发消息，messs ...

建议你好好读读NAT原理：http://www.52im.net/thread-50-1-1.html
你这种方式是行不通的。

引用：JackJiang 发表于 2017-05-10 13:38
建议你好好读读NAT原理：http://www.52im.net/thread-50-1-1.html
你这种方式是行不通的。

是啊，我知道是行不通的，所以想寻求一种可行，低耦合的解决办法。或者说QQ的udp消息是怎么做的。

谢谢大神的点拨，按照您的思路准备搭建一个im应用

引用：rickding 发表于 2017-11-23 13:48
谢谢大神的点拨，按照您的思路准备搭建一个im应用

其实有没有更加详细的ACK层的实现？目前离线消息基本都是 客户端主动调用 api 分页去拉取。然后客户端存储之后把 msg_id 发回去告诉server 我已经接收到了。

我们目前的离线思路是另一种，从业务层面弱化离线和在线的区别，群消息表内只存1条消息，send_id, group_id, msg_id。离线用户登录后不会拉取离线消息，只会获取所有会话的最新msgid或者时间，只有当用户进入特定的聊天界面时，才会实时触发拉取消息流程，此时根据最新msgid分页往前倒推获取，没有截止时间点，只要用户在界面上拉刷新，就会获取上一页msg。
1.这里其实是获取历史消息，将离线消息拉取场景也当做了历史消息拉取的一种
2.实时触发拉取，因为就算是登录时拉取了离线消息，也只有在用户点击进去相应的聊天界面这些消息才有用处（即用户点进去看这些消息）
3.假设有大量离线客户端同时登录，这里将登录时的大量统一拉取分散到了登录后的实时拉取，理论上应该是分散和随机的，可减少服务端的瞬时请求量