默认
打赏 发表评论 23
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
IM群聊消息的已读回执功能该怎么实现?
微信扫一扫关注!

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


1、前言


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

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

timg.jpeg
▲ “已读不回”,你是这样的人吗?

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

目前市面上主流的移动端IM里,提供了已读回执的主要有阿里的钉钉、网易的易信、阿里的旺旺,如下图所示:
22.jpg    11.jpg    33.jpg
▲ 上图从左至右分别为:钉钉、易信、旺旺(千牛)

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

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

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

2、IM开发干货系列文章


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


更多群聊技术文章:


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

3、正文引言


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

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


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.jpg

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

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

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

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

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

2.jpg
对于在线的群友,收到群消息后,第一时间会ack、修改last_ack_msgid

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

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

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

6、已读回执流程的设计


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

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

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

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


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

增加了已读回执逻辑后,群消息的流程会有细微的改变,见下图:
4.jpg

接着,server收到消息后,除了要:

  • 1)将群消息落地;
  • 2)查询群里有哪些群成员,以便实施推送;

之外,还需要:

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

5.jpg

接收方修改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;
  • 发送方轮询拉取已读回执。

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

(原文链接:点此进入,有改动)

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:请教关于WebSocket客户端向服务端传值的问题下一篇:[已回复] MobileIMSDK iOS端更换域名后登录断线重连?

本帖已收录至以下技术专辑

推荐方案
评论 23
有一定的参考价值,感谢
签名: 国庆长假还没有缓过来,请让我静一静,产品狗死远点...
3 楼: 十三 Lv.2 6 年前 来自手机 | 显示全部楼层
和群消息应答差不多一个逻辑。消息回执表数据量也太大了吧,200人群100条消息,就2万条
4 楼: 十三 Lv.2 6 年前 来自手机 | 显示全部楼层
还有群聊的回执,发送者每条消息,显示已阅读,什么意思?表示所有人都看到了我这条消息了?显然不可能,或者在线群在线用户全部已读?不懂,麻烦解答下
引用:十三 发表于 2018-05-23 14:31
还有群聊的回执,发送者每条消息,显示已阅读,什么意思?表示所有人都看到了我这条消息了?显然不可能,或 ...

那肯定不是了,钉钉里大概类似于这样的:
287953b1c34414f71e72535e0a6be212.jpg
6 楼: 十三 Lv.2 6 年前 来自手机 | 显示全部楼层
那我就明白了
写的不错
签名: 星期六,那又怎样,还是得上班
一条群消息就一条回执,回执里面用一个字段来存所有已读用户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秒内算一批;写入记录也分批算一条写入就可以了.
签名: im从业10年以上,欢迎切磋![url=http://www.52im.net/static/image/smiley/default/handshake.gif]http://www.52im.net/static/image/smiley/default/handshake
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部