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。

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

业务场景：

1）一个群中有A, uid1, uid2, uid3四名成员；

2）A, uid1, uid2在线，期望实时收到在线消息；

3）uid3离线，期望未来拉取到离线消息。

其整个消息发送的流程

1）A发出群消息；

2）server收到消息后，一来要将群消息落地，二来要查询群里有哪些群成员，以便实施推送；

3）对于群成员，查询在线状态；

4）对于在线的群成员，实施推送。

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

核心问题3：如何保证接收方一定收到群消息？

答：各个收到消息后，要修改各群成员的last_ack_msgid，以告诉系统，这一条消息确认收到了。

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

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

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

核心问题4：如果ack丢失，群友会不会拉取重复的群消息？

答：会，可以根据msgid在客户端本地做去重，即使系统层面收到了重复的消息，仍然可以保证良好的用户体验。

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

已读回执流程的设计

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

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

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

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）从关联表里拉取每条消息的已读回执。

这里的初步结论是：

如果发送方在线：会实时被推送已读回执；

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

已读回执流程优化方案

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

im即时通讯开发：IM群聊消息的已读回执功能相关推荐

IM即时通讯开发群聊消息的已读回执功能该怎么实现？
我们平时在使用即时通讯应用时候,每当发出一条聊天消息,都希望对方尽快看到,并尽快回复,但对方到底有没有真的看到?我却并不知道.一个残酷的现实是,很多时候对方其实是早就已经看到了这条消息,但出出种种原因 ...
IM消息重试机制Java实现_IM群聊消息的已读回执功能该怎么实现？
本文引用了架构师之路公众号作者沈剑的文章,内容有改动,感谢原作者. 1.前言我们平时在使用即时通讯应用时候,每当发出一条聊天消息,都希望对方尽快看到,并尽快回复,但对方到底有没有真的看到?我却并不知道 ...
im即时通讯开发：群聊消息如此复杂，如何保证不丢不重
群聊已经成为主流IM软件的基本功能,不管是QQ群.还是微信群,一个群友在群内发了一条消息,那么对于IM服务器来说需要保证: 在线的群友能第一时间收到消息: 离线的群友能在登陆后收到消息. 常见的群消息 ...
IM群聊消息的已读未读功能在存储空间方面的实现思路探讨
1.引言 IM系统中,特别是在企业应用场景下,消息的已读未读状态是一个强需求. 以阿里的钉钉为例,钉钉的产品定位是用于商务交流,其"强制已读回执"功能,让职场人无法再"假 ...
大公司面试考细节，设计群聊消息的已读未读功能你说说怎么做?
一朋友和我讨论他前段时间面试某大公司的一题目 : 企业IM比如企业微信.钉钉里面的群消息的有个已读未读的功能,发送者刚发出消息时,当前群里其他群成员都是未读状态,陆陆续续有人看了这个消息,这时候消息的 ...
面试官：群聊消息的已读未读功能，你来设计一个?
欢迎关注方志朋的博客,回复"666"获面试宝典一朋友和我讨论他前段时间面试某大公司的一题目 : 企业IM比如企业微信.钉钉里面的群消息的有个已读未读的功能,发送者刚发出消息时,当 ...
面试题：群聊消息的已读未读设计
点击上方"Java之间",选择"置顶或者星标" 你关注的就是我关心的! 作者:小猿学习笔记一朋友和我讨论他前段时间面试某大公司的一题目 : 企业IM比如企业微 ...
IM即时通讯开发万人群聊消息投递方案
传统意义上的IM群聊,通常都是像微信这样的500人群,或者QQ的2000人群(QQ有3000人群,但那是单独收费的,也就意味着它并非无门槛标配,能用上的人并不多). 自从国外某号称"世界上最 ...
融云RongIMKit即时通讯开发(让我们聊起来)
1.前言现在APP功能越来越多,聊天成为很重要的一个功能,现在市面上流行的即时通讯SDK基本上只有融云和环信,而近年来融云在各个方面都有超过环信的趋势,所以在项目中用到融云的地方越来越多.那我们是不 ...

im即时通讯开发：IM群聊消息的已读回执功能

im即时通讯开发：IM群聊消息的已读回执功能相关推荐

最新文章

热门文章