引用：blackheyan 发表于 2024-03-08 15:53
发送方在线时，对于已读回执的发送，真的需要实时推送么？
答：其实不需要，发送方每发一条消息，会收到40 ...

这个看产品定义吧，已读回执实时性要求没那么高，做出的效果差不多就可以了

发送方在线时，对于已读回执的发送，真的需要实时推送么？
答：其实不需要，发送方每发一条消息，会收到40个已读回执，采用轮询拉取（例如1分钟一次，一个小时也就60个请求），可以大大降低请求量。
======================================================
轮询拉取，一次拉多少条数据是个问题吧？是所有的都拉还是拉取某一段时间的？

站长威武!

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

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

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

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

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

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

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

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

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

@JackJiang 谢谢！

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

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

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

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

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

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

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

是这个意思

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

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

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

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

写的不错

那我就明白了