用http拉

引用：zhxh007 发表于 2021-09-17 17:17
1.消息列表有两种方式，一种是不保存，完全存在客户端，来消息后，直接更新就好了 另一种是保存在服务端， ...

比我说的详细多了，感谢了

引用：椎锋陷陈 发表于 2021-09-18 10:03
我们的App在进行技术演进的时候，是把用户的相关信息从消息体中剥离出来的。
也就是本地数据库会分离出两 ...

说的好

引用：椎锋陷陈 发表于 2021-09-29 09:12
我们有一张「联系人」表，应该与你们的「好友」表性质也类似。你们这种方式属于全量更新，而我们的方式属 ...

你的做法是，服务端在更新任何一个用户的任何信息时，同时更新它的时间戳对吧

引用：椎锋陷陈 发表于 2021-09-29 13:56
刚去回顾了旧项目的代码，传递的是版本号而不是时间戳，不过原理是一样的。
服务端负责维护这个版本号， ...

了解了

引用：小张 发表于 2021-10-09 15:45
你们消息是用什么数据库存储的？我这边做法和你的一样，但是遇到个问题：单个会话的消息可能会很多很多， ...

这两篇文章有没有读一下，看看有没有参考价值：

《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》
《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》

引用：小张 发表于 2021-10-09 20:36
我这边设计，基本都是文章中的一个套路（非一次性全量拉取，采用推拉方式）。但是，这些设计方式，对于单 ...

我觉得应该从产品上定义聊天记录的有效时限，几万条消息对于用户来说，有意义吗

或者说，只尝试加载最近多少条，只在用户下拉加载更新时，再去拉取一页，这样应该会合理很多

引用：小张 发表于 2021-10-11 00:24
是的，目前特殊的会话，只能人工去删除一些。

会话太活跃的话，保存时限可以定的更短一点，否则从体验上来说，也没什么意义，那么多消息，。。

引用：小张 发表于 2021-11-16 21:33
日积月累，会话会达到2 3000个（redis中会话列表数据会达到200k），这就有可能发生redis堵塞的情况吧，有什 ...

对于redis来说，200KB缓存根本不算什么啊，具体是什么问题？

引用：小张 发表于 2021-11-16 22:08
用户登录获取一次有可能会达到10+ms了，这样不会有堵塞风险吗？
另，由于是企业IM，会话会越来越多，100 ...

堵塞？你是在考虑高并发问题吗？

引用：小张 发表于 2021-11-17 11:30
是的。高峰期可能同时2000人登录

这并不多，redis的优势就是高并发，你不用担心什么

引用：小张 发表于 2021-11-17 16:35
那对于客户端而言，市面上有没有对会话多的处理？因会话多，客户端的内存会使用的越来越多，差的手机会有 ...

你放心，微信这么流畅的原因就是各种数据都会大量缓存（包括缓存在内存中），它不崩你也能不崩，现在的手机内存都够够的