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

  • 时间:
  • 浏览:0

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

3)uid3离线,期望未来拉取到离线消息。

《IM消息送达保证机制实现(二):保证离线消息的可靠投递》

答:各个收到消息后,要修改各群成员的last_ack_msgid,以告诉系统,例如条消息确认收到了。

答:可不可不还可以 ,消息接收,实时性是核心指标。

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

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

是否是 有优化方案呢?

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

- 即时通讯开发交流3群:185926912[推荐]

对于发送方发送的任何第一根群消息,都前要知道,这条消息有几条人已读几条人未读,就前要二个多 基础表来记录例如关系。

《IM群聊消息的已读回执功能该为什么在么在在么在实现?》(本文)

会带来哪些副作用?

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

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

已读的消息,可不可不还可以 进行物理删除,而是否是 标记删除;

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

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

答:存一份,为每个成员设置二个多 群消息队列,会有少许数据冗余,何必 为宜。

核心哪些的问题1:群消息,只存一份?还是,每个成员存一份?

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

回会发送方没得线,ta会在下次登录的回会:

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

可不可不还可以 不能 ,群用户每发送第一根群消息,会有:

发送方轮询拉取已读回执。

接收方累计收到N条群消息再批量ack;

答:已读回执更新不实时,最坏的清况 下,1分钟才更新回执。当然,可不可不还可以 根据性能与产品体验来折衷配置例如轮询时间。

《IM单聊和群聊中的在线清况 同步应该用“推”还是“拉”?》

之外,还前要:

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

对于last_ack_msgid的修改,真的前要每个群消息都进行ack么?

《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》

group_users(gid, uid, last_ack_msgid);

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

《怎样才能保证IM实时消息的“时序性”与“一致性”?》

这里的初步结论是:

业务场景:

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

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

3)插入每条消息的初始回执清况 。

会带来哪些副作用?

例如流程里,假如有一天第二步消息落地完成,就能保证群消息不想丢失。

发送方在线时,对于已读回执的发送,真的前要实时推送么?

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

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

解答上述二个多 核心哪些的问题后,很容易得到群消息的核心数据特性。

《IM开发基础知识补课(一):正确理解前置HTTP SSO单点登陆接口的原理》

《通俗易懂:基于集群的移动端IM接入层负载均衡方案分享》

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

像微信原来的熟人社交工具,在产品的设计理念上,为了保持使用者的隐私性,在线清况 、已读回执等涉及隐私的功能,都可不可不还可以 不能 提供。但如此来越多如此来越多回会,尤其商务、办公场合下,不为什么在么在前要例如强反馈的工具,这对于打造高效的团队很有帮助(确实员工很反感,但老板都喜欢原来的功能,哈哈)。

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

回会发送方在线:会实时被推送已读回执;

1)发送ack请求;

4)对于在线的群成员,实施推送。

《IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议》

核心哪些的问题2:回会群消息只存一份,为什么在么在在么在知道每个成员读了哪些消息?

回会发送方没得线,会在下次在线时拉取已读回执。

一齐:

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

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

3)查询发送方在线清况 ;

回会要对进行优化,可不可不还可以 :

40个已读回执,通知给发送方。

超过N长时间的回执,归档回会删除掉。

答:可不可不还可以 利用群消息的偏序关系,记录每个成员的last_ack_msgid(last_ack_time),这条消息回会的消息已读,这条消息回会的消息未读。该方案意味,对于群内的每二个多 用户,只前要记录二个多 值即可。

40个消息,通知给群友;

核心哪些的问题3:怎样才能保证接收方一定收到群消息?

亲们儿平时在使用即时通讯应用回会,每当发出第一根聊天消息,都希望对方尽快就看,并尽快回复,但对方到底有可不可不还可以 不能 真的就看?我却何必 知道。

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

4)向发送方实时推送已读回执(回会发送方在线);

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

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

答:确实不前要,可不可不还可以 批量ack,累计收到N条群消息(例如10条),再向服务器发送一次last_ack_msgid的修改请求,一齐修改例如请求回会所有请求的已读回执,原来就能将40个发送给服务端的ack请求量,降为原来的1/10。

前面的基础知识亲们儿回会了解的差如此来越多,本节来讨论本文的重点内容,即群聊已读回执流程到底该为什么在么在在么在设计。

2)A, uid1, uid2在线,期望实时收到在线消息;

《移动端IM登录时拉取数据怎样才能作到省流量?》

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

答:回执数据是否是 核心数据

在核心数据特性设计完回会,一齐来看看群消息发送的流程(本系列中的文章《IM群聊消息可不可不还可以 不能 繁复,怎样才能保证不丢不重?》删剪讲解了例如过程,可不可不还可以 深入读一读)。

学习交流:

群成员表:记录群里的成员,以及每个成员收到的最后第一根群消息

《IM群聊消息可不可不还可以 不能 繁复,怎样才能保证不丢不重?》

2)修改last_ack_msgid,为什么在么在让,修改已读回执if_ack清况 ;

(画外音:回会直接装入去应用层keepalive请求里,做到0额外请求增加。)

《IM消息送达保证机制实现(二):保证离线消息的可靠投递》

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

群消息的推送,可不可不还可以 改为接收方轮询拉取?

可不可不还可以 不能 群聊消息的收发流程、消息的送达保证、已读回执机制,到底该为什么在么在在么在实现呢?这而是今天要讨论句子题。

回会发送方没得线:会在下次在线时拉取已读回执。

核心哪些的问题4:回会ack丢失,群友会不想拉取重复的群消息?

二个多 残酷的现实是,如此来越多如此来越多回会对方确实是早就回会就看了这条消息,但出出种种意味(亲们儿都懂的),通常是否是 默默返回——假装没看见。

群消息表:记录群消息

怎样才能降低数据量?

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

各字段的含义为:群ID,群成员UID,群成员最后收到的第一根群消息ID。

3)对于群成员,查询在线清况 ;

《IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token》

2)查询群里哪些群成员,以便实施推送;

《IM群聊消息可不可不还可以 不能 繁复,怎样才能保证不丢不重?》

1)二个多 群含高A, uid1, uid2, uid3四名成员;

40个ack修改last_ack_msgid,发给服务端;

答:last_ack_msgid的作用是,记录接收方最近新取的第一根群消息,回会不实时更新,回会意味,异常退出时,有其他群消息没来得及更新last_ack_msgid,使得下次登陆时,会拉取到重复的群消息。但这都哪些的问题,客户端可不可不还可以 根据msgid去重,用户体验不想受影响。

接收方修改last_ack_msgid的流程,会变为:

答:确实不前要,发送方每发第一根消息,会收到40个已读回执,采用轮询拉取(例如1分钟一次,二个多 小时也就1000个请求),可不可不还可以 大大降低请求量。

1)A发出群消息;

首先亲们儿前要了解一下群消息的设计、投递流程以及可达性保证机制,因是否是 本文要讨论的重点,如此来越多如此来越多尽量言简意赅,更删剪的资料请见下方的推荐文章列表。

回会发送方在线,会实时被推送已读回执;

《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》

群数量,群友数量,群消息数量如此来越多回会,存储也会成为哪些的问题。

《浅谈移动端IM的多点登陆和消息漫游原理》

《例如Android端IM智能心跳算法的设计与实现探讨(含样例代码)》

1)将群消息落地;

目前市面上主流的移动端IM里,提供了已读回执的主要有阿里的钉钉、网易的易信、阿里的旺旺,如下图所示:

《IM开发基础知识补课(二):怎样才能设计少许图片文件的服务端存储架构?》

《怎样才能保证IM实时消息的“时序性”与“一致性”?》

亲们儿一齐跟着楼主的节奏,一步一步来看群消息为什么在么在在么在设计。

前要存储40条ack记录。

对于群消息已读回执,一般来说: