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这个文章冲突了，因为有收件箱了