IM群聊消息的已读回执功能该怎么实现？

本文引用了架构师之路公众号作者沈剑的文章，即时通讯网对内容有改动，感谢原作者。

1、前言

我们平时在使用即时通讯应用时候，每当发出一条聊天消息，都希望对方尽快看到，并尽快回复，但对方到底有没有真的看到？我却并不知道。

一个残酷的现实是，很多时候对方其实是早就已经看到了这条消息，但出出种种原因（大家都懂的），通常都是默默返回——假装没看见（就像下图带给你的感觉——简单直接、冷酷无情）。


▲ “已读不回”，你是这样的人吗？

像微信这样的熟人社交工具，在产品的设计理念上，为了保持使用者的隐私性，在线状态、已读回执等涉及隐私的功能，都没有提供（详见：《IM热门功能讨论：为什么微信里没有消息“已读”功能？》）。但很多时候，尤其商务、办公场合下，特别需要一种强反馈的工具，这对于打造高效的团队很有帮助（虽然员工很反感，但老板都喜欢这样的功能，哈哈）。

目前市面上主流的移动端IM里，提供了已读回执的主要有阿里的钉钉、网易的易信、阿里的旺旺，如下图所示：
     
▲ 上图从左至右分别为：钉钉、易信、旺旺（千牛）

以阿里的钉钉为例，钉钉的产品定位是用于商务交流，其“强制已读回执”功能，让职场人无法再“假装不在线”、“假装没收到”。更有甚者，钉钉的群聊“强制已读回执”功能，甚至能够知道谁读了消息，谁没有读消息（老板的福音啊）。

那么群聊消息的收发流程、消息的送达保证、已读回执机制，到底该怎么实现呢？这就是今天要讨论的话题。

推荐阅读：《IM群聊消息的已读未读功能在存储空间方面的实现思路探讨》。

2、IM开发干货系列文章

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

• 《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开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

3、正文引言

首先我们需要了解一下群消息的设计、投递流程以及可达性保证机制，因不是本文要讨论的重点，所以尽量言简意赅，更详细的资料请见下方的推荐文章列表。

如您对聊天消息的投递和送达机制等尚无概念，可先读本系列文章的以下几篇，有助于您详细掌握这方面的内容：

• 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
• 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
  

4、群消息怎么设计？

大家一起跟着楼主的节奏，一步一步来看群消息怎么设计。

核心问题1：群消息，只存一份？还是，每个成员存一份？
答：存一份，为每个成员设置一个群消息队列，会有大量数据冗余，并不合适。

核心问题2：如果群消息只存一份，怎么知道每个成员读了哪些消息？
答：可以利用群消息的偏序关系，记录每个成员的last_ack_msgid（last_ack_time），这条消息之前的消息已读，这条消息之后的消息未读。该方案意味着，对于群内的每一个用户，只需要记录一个值即可。

解答上述两个核心问题后，很容易得到群消息的核心数据结构。

群消息表：记录群消息

group_msgs(msgid, gid, sender_uid, time, content);

各字段的含义为：消息ID，群ID，发送方UID，发送时间，发送内容。

群成员表：记录群里的成员，以及每个成员收到的最后一条群消息

group_users(gid, uid, last_ack_msgid);

各字段的含义为：群ID，群成员UID，群成员最后收到的一条群消息ID。

5、了解一下群消息发送的流程

在核心数据结构设计完之后，一起来看看群消息发送的流程（本系列中的文章《IM群聊消息如此复杂，如何保证不丢不重？》详细讲解了这个过程，可以深入读一读）。

业务场景：

• 1）一个群中有A, uid1, uid2, uid3四名成员；
• 2）A, uid1, uid2在线，期望实时收到在线消息；
• 3）uid3离线，期望未来拉取到离线消息。
  

其整个消息发送的流程1-4如上图：

• 1）A发出群消息；
• 2）server收到消息后，一来要将群消息落地，二来要查询群里有哪些群成员，以便实施推送；
• 3）对于群成员，查询在线状态；
• 4）对于在线的群成员，实施推送。
  

这个流程里，只要第二步消息落地完成，就能保证群消息不会丢失。

核心问题3：如何保证接收方一定收到群消息？
答：各个收到消息后，要修改各群成员的last_ack_msgid，以告诉系统，这一条消息确认收到了。

在线消息，离线消息的last_ack_msgid的修改，又各有不同。


对于在线的群友，收到群消息后，第一时间会ack、修改last_ack_msgid。


对于离线的群友，会在下一次登录时，拉取未读的所有群离线消息，并将last_ack_msgid修改为最新的一条消息。

核心问题4：如果ack丢失，群友会不会拉取重复的群消息？
答：会，可以根据msgid在客户端本地做去重，即使系统层面收到了重复的消息，仍然可以保证良好的用户体验。

上述流程，只能确保接收方收到消息，发送方仍然不知道哪些人在线阅读了消息，哪些人离线未阅读消息，并没有实现已读回执，那已读回执会对系统设计产生什么样的影响呢？

6、已读回执流程的设计

前面的基础知识我们已经了解的差不多，本节来讨论本文的重点内容，即群聊已读回执流程到底该怎么设计。

对于发送方发送的任何一条群消息，都需要知道，这条消息有多少人已读多少人未读，就需要一个基础表来记录这个关系。

消息回执表：用来记录消息的已读回执

msg_acks(sender_uid, msgid, recv_uid, gid,if_ack);

各字段的含义为：发送方UID，消息ID，回执方UID，群ID，回执标记。

增加了已读回执逻辑后，群消息的流程会有细微的改变，见下图：


接着，server收到消息后，除了要：

• 1）将群消息落地；
• 2）查询群里有哪些群成员，以便实施推送；
  

之外，还需要：

• 3）插入每条消息的初始回执状态。
  

接收方修改last_ack_msgid的流程，会变为：

• 1）发送ack请求；
• 2）修改last_ack_msgid，并且，修改已读回执if_ack状态；
• 3）查询发送方在线状态；
• 4）向发送方实时推送已读回执（如果发送方在线）；
  

如果发送方不在线，ta会在下次登录的时候：

• 5）从关联表里拉取每条消息的已读回执。
  

这里的初步结论是：

• 如果发送方在线：会实时被推送已读回执；
• 如果发送方不在线：会在下次在线时拉取已读回执。
  

7、已读回执流程优化方案

再次详细的分析下，群消息已读回执的“消息风暴扩散系数”，假设每个群有200个用户，其中20%的用户在线，即40各用户在线。

那么，群用户每发送一条群消息，会有：

• 40个消息，通知给群友；
• 40个ack修改last_ack_msgid，发给服务端；
• 40个已读回执，通知给发送方。
  

可见，其消息风暴扩散系数非常之大。

同时：

• 需要存储40条ack记录。
  

群数量，群友数量，群消息数量越来越多之后，存储也会成为问题。

是否有优化方案呢？

群消息的推送，能否改为接收方轮询拉取？
答：不能，消息接收，实时性是核心指标。

对于last_ack_msgid的修改，真的需要每个群消息都进行ack么？
答：其实不需要，可以批量ack，累计收到N条群消息（例如10条），再向服务器发送一次last_ack_msgid的修改请求，同时修改这个请求之前所有请求的已读回执，这样就能将40个发送给服务端的ack请求量，降为原来的1/10。

会带来什么副作用？
答：last_ack_msgid的作用是，记录接收方最近新取的一条群消息，如果不实时更新，可能导致，异常退出时，有一些群消息没来得及更新last_ack_msgid，使得下次登陆时，会拉取到重复的群消息。但这不是问题，客户端可以根据msgid去重，用户体验不会受影响。

发送方在线时，对于已读回执的发送，真的需要实时推送么？
答：其实不需要，发送方每发一条消息，会收到40个已读回执，采用轮询拉取（例如1分钟一次，一个小时也就60个请求），可以大大降低请求量。
（画外音：或者直接放到应用层keepalive请求里，做到0额外请求增加。）

会带来什么副作用？
答：已读回执更新不实时，最坏的情况下，1分钟才更新回执。当然，可以根据性能与产品体验来折衷配置这个轮询时间。

如何降低数据量？
答：回执数据不是核心数据

• 已读的消息，可以进行物理删除，而不是标记删除；
• 超过N长时间的回执，归档或者删除掉。
  

8、本文小结

对于群消息已读回执，一般来说：

• 如果发送方在线，会实时被推送已读回执；
• 如果发送方不在线，会在下次在线时拉取已读回执。
  

如果要对进行优化，可以：

• 接收方累计收到N条群消息再批量ack；
• 发送方轮询拉取已读回执。
  

物理删除已读回执数据，定时删除或归档非核心历史数据。

（原文链接：点此进入，有改动）

有一定的参考价值，感谢

和群消息应答差不多一个逻辑。消息回执表数据量也太大了吧，200人群100条消息，就2万条

还有群聊的回执，发送者每条消息，显示已阅读，什么意思？表示所有人都看到了我这条消息了？显然不可能，或者在线群在线用户全部已读?不懂，麻烦解答下

引用：十三 发表于 2018-05-23 14:31
还有群聊的回执，发送者每条消息，显示已阅读，什么意思？表示所有人都看到了我这条消息了？显然不可能，或 ...

那肯定不是了，钉钉里大概类似于这样的：

那我就明白了

写的不错

一条群消息就一条回执，回执里面用一个字段来存所有已读用户Id集合，这样是否可行？

引用：wucan_dan 发表于 2018-06-15 15:06
一条群消息就一条回执，回执里面用一个字段来存所有已读用户Id集合，这样是否可行？

不可行，如果1000个人已读，那1000个id的集合，这数据量对于一条im协议报文来说算是很大了

这个ack表示的是消息已经到了客户端，但是读没读是用户的行为吧，或者说当消息在屏幕上划过时，才能叫已读吧，前者叫已收，后者叫已读

引用：dangxy 发表于 2018-09-06 11:24
这个ack表示的是消息已经到了客户端，但是读没读是用户的行为吧，或者说当消息在屏幕上划过时，才能叫已读 ...

是这个意思

写的很清晰，受益良多。
主动轮询回执的流程中，假设1分钟内发了10条消息，那么一次拉取便要获取400个回执数据，相比实时推送虽然大大减少了整体请求数，但可能某次请求会传输较大数据量。根据前面几篇文章的处理方式，此处也可使用分页的方式，虽多了几次请求，但比起推送的方式仍是少的多了。
再一个觉得回执本身就是一个大数据量的业务场景，一个群在线用户N个的系统，平均每群每天M条消息，一天光存储回执就N * M 条数据了，百万在线用户，百条消息，这就日均亿级了

引用：weixiaoyao 发表于 2019-01-04 18:35
写的很清晰，受益良多。
主动轮询回执的流程中，假设1分钟内发了10条消息，那么一次拉取便要获取400个回执 ...

是的，其实回执本身就是消息的冗余分身，不过好在它是专用指令，可以针对性优化，但不管怎么说要实现它会降低整体系统的有效消息吞吐量，这就是代价。谁让老板拍瞎拍脑袋，就做就得做呢

消息风暴扩散系数 ， 我考虑，能不能做个消息偏移量的处理方式，已读更新消息读取偏移量。

引用：laojichuxin 发表于 2019-07-26 18:14
消息风暴扩散系数 ， 我考虑，能不能做个消息偏移量的处理方式，已读更新消息读取偏移量。

是的，你的点子不错，而且很符合客户端跟UI的配合实现方式

群成员表：记录群里的成员，以及每个成员收到的最后一条群消息
group_users(gid, uid, last_ack_msgid);

如果需要支持多种客户端怎么设计呢，比方说需要同时支持手机和pc端，上面这个表是否要改为：
group_users (gid, uid, uid_type, last_ack_msgid)

@JackJiang 谢谢！

引用：danielstock 发表于 2020-06-08 16:05
群成员表：记录群里的成员，以及每个成员收到的最后一条群消息
group_users(gid, uid, last_ack_msgid);
...

你这种，就应该以客户端记录的last_ack_msgid为准了，不然会把服务端搞复杂

引用：dangxy 发表于 2018-09-06 11:24
**** 作者被禁止或删除 内容自动屏蔽 ****

钉钉是打开对话窗口后标记为已读 ，按照笔者的描述是已读 其实应该是已收到信 （钉钉：当不再对话窗口是可以实时收到消息并查看，但并不是已读）

已读回执的记录写入会不会有问题。群200个人，一个消息来了就要写200个未读回执记录？

引用：ZJoker 发表于 2022-11-04 15:28
已读回执的记录写入会不会有问题。群200个人，一个消息来了就要写200个未读回执记录？

可以分批处理,刚发完消息例如5秒内算一批;写入记录也分批算一条写入就可以了.