引用：jmye222 发表于 2024-03-20 16:15
12楼这种情况有没有比较好的解决方案分享下？

对于真正的用户来说，他们双方又不是脸贴脸像你测试时这样去用，对方那几条消息到底有没有真的已读，真要去精确地纠结它，意义不太大，别太沉迷于技术不能自拨了。这种功能相比于保证消息不丢来说，可以不用100%较真，差不多就行了

12楼这种情况有没有比较好的解决方案分享下？

强强强

这不就是写扩散转读扩散吗

能否讲讲客户端消息的融合。。比如离线后群有100条消息。读了最后20条，只会又离线。又多了50条。
这时候又读最后20条。往上读30条后。他就遇到老消息了。这时候他怎么知道前面20条已读的之后还有80条未读的？

引用：fzully 发表于 2020-07-14 23:09
小弟我是用队列解耦，分布式设计普遍会这么玩的吧

大佬，什么时间讲讲离线消息的多端同步？

666

引用：clark.li 发表于 2020-07-14 14:22
一直关注52im，大牛的这篇虽然没有高大上，但是很接地气，特地登陆回复。

另外，请问大牛，你的im里有没 ...

小弟我是用队列解耦，分布式设计普遍会这么玩的吧

引用：天黑请闭嘴 发表于 2020-07-14 14:07
感谢大牛的分享，读完了你的文章，基于会话列表这个方案，前提是你的服务端完整存储了所有聊天的记录内容 ...

服务端是得有完整记录，那些只需发在线的消息除外。游标在客户端手上，同一个用户的不同设备游标可能不一样，各自拿游标去同步即可。

一直关注52im，大牛的这篇虽然没有高大上，但是很接地气，特地登陆回复。

另外，请问大牛，你的im里有没有用到集群？如果有，那么im集群中的socket长连接接入层跟业务逻辑层的通信，你是用RPC来实现的吗？

引用：fzully 发表于 2020-07-14 12:01
大哥评价很在理！其中，针对第3点的体验，可在客户端取到会话列表时，对有未读条目的会话，App主动取一次 ...

感谢大牛的分享，读完了你的文章，基于会话列表这个方案，前提是你的服务端完整存储了所有聊天的记录内容对吧？

不然，多端同步、分段拉取都很难实现。

引用：fzully 发表于 2020-07-14 12:01
大哥评价很在理！其中，针对第3点的体验，可在客户端取到会话列表时，对有未读条目的会话，App主动取一次 ...

活捉作者。感谢大佬的分享。

引用：tangtao 发表于 2020-07-14 11:08
文章很好  会话维护模式 多端同步下很复杂 ，还是学微信的：消息只存指定的天数然后采用离线拉取模式 感觉 ...

大哥评价很在理！其中，针对第3点的体验，可在客户端取到会话列表时，对有未读条目的会话，App主动取一次同步（返回条目数 <= 一个屏幕显示的条数，因为客户端缺的消息可能只有几条）。
我在整理文字时有失误，确实不用让用户点击会话才触发首次同步，多谢指正！

引用：tangtao 发表于 2020-07-14 11:08
文章很好  会话维护模式 多端同步下很复杂 ，还是学微信的：消息只存指定的天数然后采用离线拉取模式 感觉 ...

看的出来，是枚im开发老油条了

文章很好  会话维护模式 多端同步下很复杂 ，还是学微信的：消息只存指定的天数然后采用离线拉取模式 感觉还行。

如果不像作者一样不到万不得已我觉得还是采用全量拉消息好点。

因为如果是服务端维护会话：

• 第一：消息搜索只能走服务端的搜索，
• 第二：会话有很多状态比如有 [转账]，有人@我 [红包] 等等这些状态就需要服务端维护了
• 第三：用户进入会话刷消息体验相比第一种方式要差  
• 第四：服务端和客户端实现第二种方式都比第一种方式复杂。