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

你们消息是用什么数据库存储的？我这边做法和你的一样，但是遇到个问题：单个会话的消息可能会很多很多，比如1周聊了5w条数据，1个月10w条数据，当客户端进行差量拉取，是根据一个序列号（类似时间戳）进行分页拉取。用关系型数据库或分布式数据库对这种单个会话很多消息记录的情况，会查询的很慢，因为还需要进行排序后再获取对应N条的记录。有没有好的建议解决这个问题？谢谢

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

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

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

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

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

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

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

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

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

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

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

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

嗯，这个方向是可以。

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

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

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

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

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

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

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

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