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

时间 2019-12-20

标签消息回执功能怎么实现繁體版

原文原文链接

本文引用了架构师之路公众号做者沈剑的文章，内容有改动，感谢原做者。html

一、前言

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

一个残酷的现实是，不少时候对方实际上是早就已经看到了这条消息，但出出种种缘由（你们都懂的），一般都是默默返回——伪装没看见。

像微信这样的熟人社交工具，在产品的设计理念上，为了保持使用者的隐私性，在线状态、已读回执等涉及隐私的功能，都没有提供。但不少时候，尤为商务、办公场合下，特别须要一种强反馈的工具，这对于打造高效的团队颇有帮助（虽然员工很反感，但老板都喜欢这样的功能，哈哈）。

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

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

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

学习交流：数据库

- 即时通信开发交流3群：185926912[推荐]服务器

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》微信

（本文同步发布于：http://www.52im.net/thread-1611-1-1.html）数据结构

二、IM开发干货系列文章

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

架构

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

三、正文引言

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

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

工具

四、群消息怎么设计？

你们一块儿跟着楼主的节奏，一步一步来看群消息怎么设计。

核心问题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。

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

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

业务场景：

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

<ignore_js_op>

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

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

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

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

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

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

<ignore_js_op>
对于离线的群友，会在下一次登陆时，拉取未读的全部群离线消息，并将last_ack_msgid修改成最新的一条消息。

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

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

六、已读回执流程的设计

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

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

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

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

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

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

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

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

以外，还须要：

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

<ignore_js_op>

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

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

若是发送方不在线，ta会在下次登陆的时候：

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

这里的初步结论是：

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

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

再次详细的分析下，群消息已读回执的“消息风暴扩散系数”，假设每一个群有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长时间的回执，归档或者删除掉。

八、本文小结

对于群消息已读回执，通常来讲：

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

若是要对进行优化，能够：

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

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

（本文同步发布于：http://www.52im.net/thread-1611-1-1.html）