默认
开启辅助访问
即时通讯网»社区 › 专项技术区 › IM开发 › IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写) ...

IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？

查看数: 391855 | 评论数: 50 | 收藏 15
关灯 | 提示：支持键盘翻页<-左 右->
帖子模式
    组图打开中，请稍候......
JackJiang
发布时间: 2018-05-25 11:48

正文摘要:

1、前言 IM的群聊消息，究竟存1份（即扩散读方式）还是存多份（即扩散写方式）？ 上一篇文章《IM群聊消息的已读回执功能该怎么实现？》里说，“很容易想到，是存一份”，被网友们骂了，大家争论的很激烈（见下图 ...

评论

苏门答腊伟 发表于 3 个月前
终极方案是不是和http://www.52im.net/forum.php?mod=viewthread&tid=1230这个文章冲突了，因为有收件箱了
苏门答腊伟 发表于 3 个月前
当同时有单聊和群聊的时候，单聊用的是写扩散，有收信箱，群聊好像存储方式又不同，这里的会话列表设计应该是什么样的呢，两者结合又需要根据时序。。
ZJoker 发表于 12 个月前
引用：researchboy 发表于 2018-07-09 20:27
我们现实方案与最后一种方案不谋而合

这有个问题，就是重连初始化更新会话列表状态信息时，读扩散的话就会去拉取每个会话和计算未读。有点麻烦。
BrainWong 发表于 1 年前
目前在遇到一个困扰，如果是维护一个last_id。
假设发生了这种场景，last_id + 1消息在中途丢失了，而last_id + 3 消息先达到客户端，客户端先收到了last_id +3的消息，而丢失了后面两个消息。

是不是客户端必须实现类似于滑动窗口这种去重机制，同时还必须搭配比较强的全局唯一自增id才能解决。有没有更廉价的方案，比如，只需要id自增，而不需要严格连续。
crazyerror 发表于 2 年前
终极方案里，假设id递增的msg1，msg2，msg3；msg3应答了，msg2没有应答；这时last_ack_msgid该怎么处理呢？

暂时想到客户端存储一个最后一次离线消息ID， 没有按照离线消息ID 批量拉取消息，然后去重，不知道有什么更好的设计方法，这样子每个消息被多拉了1次。
LBY 发表于 2 年前
优化为：
group_members(gid, uid, last_ack_msgid);
group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid); // 不再需要
-----------------------------

这里好像没考虑多终端在线的情况吧？last_ack_msgid跟用户id层面绑定的话
逍遥小子 发表于 2 年前
引用：1mok 发表于 2019-03-06 18:06
服务端肯定是可以计算出，但问题的关键是效率。一个人的会话数很多的时候（无限建群模式），如何快速找到 ...

消息同步模型，如果是有新消息来，先推送新消息的通知给接收端，接收端来从库里面拉取消息。
如果在读扩散的模型下， 推送新消息通知的时候带上群ID或者发送方ID，然后接收端按照群ID来拉取消息，不知道这样的做法是不是可以解决找到未读消息的会话列表。
JackJiang 发表于 3 年前
引用：sidney 发表于 2021-05-06 19:35
终极方案的群成员只有在一个群只记录一个last_ack_msgid   怎么处理群成员在离线情况下，用户被频繁的拉进 ...

不用想这么复杂，就保留最后一个操作记录就好了。
用产品经理的话说：哪有那么多神经病，一会进群、一会被踢、一会又拉进群。。。。

sidney 发表于 3 年前
终极方案的群成员只有在一个群只记录一个last_ack_msgid   怎么处理群成员在离线情况下，用户被频繁的拉进群、踢出群、还能正确的只拉取到在群期间应该看到的消息？
例如 群聊A里面发送了消息1、2 、3 、4、5 、 6 、7 、 8 、9
用户在消息2之后3之前被拉进了群聊A，然后再消息4之后5之前踢出了群聊A又在消息7之后8之前拉进了群聊A
当用户再次上线时应该收取到群聊A的消息3、 4 、 8、 9
JackJiang 发表于 3 年前
引用：weixiaoyao 发表于 2021-03-30 17:49
Jack Jiang就是沈剑老师么？

不是
weixiaoyao 发表于 3 年前
Jack Jiang就是沈剑老师么？
JackJiang 发表于 3 年前
引用：GarageBand 发表于 2020-11-03 11:53
比如说一个用户有八个群，是每个群都对应一个last_ack_msgid，还是所有群对应一个last_ack_msgid？

从技术实现的复杂度上来说，如是能做到全局唯一消息id的话，所有群用一个id是最简单经济的
GarageBand 发表于 3 年前
引用：JackJiang 发表于 2020-09-04 21:31
是的

比如说一个用户有八个群，是每个群都对应一个last_ack_msgid，还是所有群对应一个last_ack_msgid？
JackJiang 发表于 3 年前
引用：张小驰_q6jys 发表于 2020-10-29 15:35
微信生成消息ID 里提到按用户生成msgid，那群消息只存一份，群中各个用户的msgid和群消息是如何关联的？

群消息是一个表，每个群还有个群成员表，在群成员表上针对各人做文章
张小驰_q6jys 发表于 3 年前
微信生成消息ID 里提到按用户生成msgid，那群消息只存一份，群中各个用户的msgid和群消息是如何关联的？
JackJiang 发表于 3 年前
引用：GarageBand 发表于 2020-09-04 20:11
客户端拉取携带服务端返回给他最新的last_ack_msgid，服务端只返回比last_ack_msgid大的消息列表给客户端？ ...

是的
GarageBand 发表于 3 年前
客户端拉取携带服务端返回给他最新的last_ack_msgid，服务端只返回比last_ack_msgid大的消息列表给客户端？避免重复拉取。
JackJiang 发表于 3 年前
引用：Sudo 发表于 2020-04-19 23:50
我和你有同样的疑问, 读扩散模式下如何快速找到有新消息的会话..
目前思路是不写db, 但要记在缓存里. 把 ...

性能上，放到缓存肯定是最优项。
Monkey 发表于 3 年前
学习了
Sudo 发表于 4 年前
引用：1mok 发表于 2019-03-06 18:06
服务端肯定是可以计算出，但问题的关键是效率。一个人的会话数很多的时候（无限建群模式），如何快速找到 ...

我和你有同样的疑问, 读扩散模式下如何快速找到有新消息的会话..
目前思路是不写db, 但要记在缓存里. 把有新消息的会话id记录下来.

返回顶部