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

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

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

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

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

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

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

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

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

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

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

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

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