请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 50
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
Jack Jiang就是沈剑老师么?
引用:weixiaoyao 发表于 2021-03-30 17:49
Jack Jiang就是沈剑老师么?

不是
终极方案的群成员只有在一个群只记录一个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
引用:sidney 发表于 2021-05-06 19:35
终极方案的群成员只有在一个群只记录一个last_ack_msgid   怎么处理群成员在离线情况下,用户被频繁的拉进 ...

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

引用:1mok 发表于 2019-03-06 18:06
服务端肯定是可以计算出,但问题的关键是效率。一个人的会话数很多的时候(无限建群模式),如何快速找到 ...

消息同步模型,如果是有新消息来,先推送新消息的通知给接收端,接收端来从库里面拉取消息。
如果在读扩散的模型下, 推送新消息通知的时候带上群ID或者发送方ID,然后接收端按照群ID来拉取消息,不知道这样的做法是不是可以解决找到未读消息的会话列表。
优化为:
group_members(gid, uid, last_ack_msgid);
group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid); // 不再需要
-----------------------------

这里好像没考虑多终端在线的情况吧?last_ack_msgid跟用户id层面绑定的话
终极方案里,假设id递增的msg1,msg2,msg3;msg3应答了,msg2没有应答;这时last_ack_msgid该怎么处理呢?

暂时想到客户端存储一个最后一次离线消息ID, 没有按照离线消息ID 批量拉取消息,然后去重,不知道有什么更好的设计方法,这样子每个消息被多拉了1次。
目前在遇到一个困扰,如果是维护一个last_id。
假设发生了这种场景,last_id + 1消息在中途丢失了,而last_id + 3 消息先达到客户端,客户端先收到了last_id +3的消息,而丢失了后面两个消息。

是不是客户端必须实现类似于滑动窗口这种去重机制,同时还必须搭配比较强的全局唯一自增id才能解决。有没有更廉价的方案,比如,只需要id自增,而不需要严格连续。
签名: 难受,今年互联网还有机会吗
引用:researchboy 发表于 2018-07-09 20:27
我们现实方案与最后一种方案不谋而合

这有个问题,就是重连初始化更新会话列表状态信息时,读扩散的话就会去拉取每个会话和计算未读。有点麻烦。
当同时有单聊和群聊的时候,单聊用的是写扩散,有收信箱,群聊好像存储方式又不同,这里的会话列表设计应该是什么样的呢,两者结合又需要根据时序。。
终极方案是不是和http://www.52im.net/forum.php?mod=viewthread&tid=1230这个文章冲突了,因为有收件箱了
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部