求教IM里聊天列表的获取和发送人信息的获取，怎么做合适？

在IM开发，用户登录后，获取用户的聊天列表用什么方式比较好呢，是把聊天列表信息存在本地嘛，每次登录从本地拿，想了一会，发现这个消息列表不好实时保存呀，还有一个疑问，使用socket通信的时候，如果获取发送人的信息，如头像，昵称之类的，可以在socket的消息体里面多加一个是来保存发送人的信息嘛，这样会不会消息体会不会很啰嗦

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

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

引用：JackJiang 发表于 2021-11-17 11:33
这并不多，redis的优势就是高并发，你不用担心什么

那对于客户端而言，市面上有没有对会话多的处理？因会话多，客户端的内存会使用的越来越多，差的手机会有问题

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

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

引用：JackJiang 发表于 2021-11-16 22:23
堵塞？你是在考虑高并发问题吗？

是的。高峰期可能同时2000人登录

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

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

引用：JackJiang 发表于 2021-11-16 21:56
对于redis来说，200KB缓存根本不算什么啊，具体是什么问题？

用户登录获取一次有可能会达到10+ms了，这样不会有堵塞风险吗？
另，由于是企业IM，会话会越来越多，1000->2000->...有可能一直下去，那样也会越来越大数据了。行业有没有什么好的策略学习下？

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

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

日积月累，会话会达到2 3000个（redis中会话列表数据会达到200k），这就有可能发生redis堵塞的情况吧，有什么好策略可以解决日积月累的会话数吗？

对于会话列表太多有什么好的策略吗？文章中的是把会话列表存在redis中，但是，如果达到2 3000个会话（200kb），也是会挺大的数据量吧，对于redis来说，有可能会发生堵塞情况吧

引用：JackJiang 发表于 2021-10-11 10:20
会话太活跃的话，保存时限可以定的更短一点，否则从体验上来说，也没什么意义，那么多消息，。。

嗯，这个方向是可以。

引用：椎锋陷陈 发表于 2021-10-11 10:00
「基于时间序的数据都天然带有冷热分明属性」，即用户通常只关心最新最近的数据，而很少会追溯到很久以前 ...

谢谢你的分析，可能我表述不清楚，并不是一下拉几万条，其实我这边是设计和文章的95%一样。只是目前，对于单个会话有可能短期内用户聊天太多，导致数据库查询较慢。也许我这边需要在sql或者对这些单个会话太多的想些策略，比如只给使用N条记录，超过就当成冷数据不给使用之类的。

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

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

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

「基于时间序的数据都天然带有冷热分明属性」，即用户通常只关心最新最近的数据，而很少会追溯到很久以前的数据。
我们App最初的架构是不支持多端同步和消息漫游的，对于离线消息的存储也是有一定的时间限制的，超过这个时间没有拉取的就不保留了，
这样做也是基于聊天数据冷热分明属性的考虑。

至于针对你这种情况的做法，Jack Jiang大佬已经说了，「只尝试加载最近多少条，只在用户下拉加载更新时，再去拉取一页」，
我再补充一点，每个会话的未读消息的数目你可以另外单独推送，这样，在用户的角度上能得知正确的消息未读数，感觉是消息已经全部拉下来了，
在使用上由于进行了分页加载，避免了一下子同步几万条消息形成瓶颈从而造成卡顿甚至ANR，用户体验也就更友好。

引用：林北lpepsi 发表于 2021-09-29 16:00
你们这个同步方法是只处理增量好友吗，无论之前的好友的个人信息是否修改都不在这个方法返回。然后再用另 ...

处理包括新增的好友信息以及有变动的好友信息，都是在这个接口返回的。

引用：厚礼蟹不肉 发表于 2021-09-29 15:53
你们这个同步方法是只管好友有没有增量吗，对于之前的好友的个人信息是否修改不在这里返回。再用另外的接 ...

这里所谓的增量更新，内容就包括新增的好友信息以及有变动的好友信息，都是在启动时的同步好友接口返回的。

引用：JackJiang 发表于 2021-10-10 17:46
我觉得应该从产品上定义聊天记录的有效时限，几万条消息对于用户来说，有意义吗

或者说，只尝试加载最 ...

是的。目前也是一页一页的拉取，也许我的sql索引设计有问题，研究研究看能否通过修改方式优化查询

引用：JackJiang 发表于 2021-10-10 17:46
我觉得应该从产品上定义聊天记录的有效时限，几万条消息对于用户来说，有意义吗

或者说，只尝试加载最 ...

是的，目前特殊的会话，只能人工去删除一些。

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

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

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

引用：JackJiang 发表于 2021-10-09 16:00
这两篇文章有没有读一下，看看有没有参考价值：

《IM开发干货分享：我是如何解决大量离线消息导致客户 ...

我这边设计，基本都是文章中的一个套路（非一次性全量拉取，采用推拉方式）。但是，这些设计方式，对于单个会话消息记录很多，感觉总会有瓶颈，比如A群，2天聊了2w条数据，1周聊了5w条数据，客户端进行缺失消息同步时，服务端的数据库查询就需要扫描N万条记录，再取出M条，会查询的很慢慢慢。

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

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

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