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

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

用http拉

1.消息列表有两种方式，一种是不保存，完全存在客户端，来消息后，直接更新就好了 另一种是保存在服务端，为了减少每次拉取量，需要做增量拉取
2.为了保持消息体简洁和减少流量，消息体里不要带多余的用户信息，只带用户id，收到后发现本地没有用户信息，单独通过接口去拉取额外的信息，拉取后缓存到本地，然后在合适的时机更新就行了

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

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

我们的App在进行技术演进的时候，是把用户的相关信息从消息体中剥离出来的。
也就是本地数据库会分离出两张表，一张Message表，一张User表。
Message表只会保留收发对象的用户ID，User表保留所有接触过的用户信息(单聊对象、群成员等)。

查询数据时两个表进行联表查询，展示为MessageVO(视图对象，包含消息与必要的用户信息)，
发送消息同样只会携带收发对象的用户ID。

我们在每次启动时必定会执行几项工作：同步离线消息/同步会话/同步好友/同步群组，
本地都会保留一个最后更新的时间戳，以便下次请求时进行增量更新而非全量更新，减少请求数据量。
同步好友操作时就会对好友的用户信息进行更新。
另外就是在收取消息时，发现本地User表没有相关信息时，就会主动请求接口更新用户信息。

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

说的好

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

你好我想请教一下你们每次登录启动的时候，同步好友的时候，是会有一张好友表吗。我现在是每次登录的同时，获取当前用户的所有好友，然后把本地好友表的数据全部清空，再插入一遍，你说的保留最后更新的时间戳，好友表要怎么保存呢

引用：厚礼蟹不肉 发表于 2021-09-28 23:27
你好我想请教一下你们每次登录启动的时候，同步好友的时候，是会有一张好友表吗。我现在是每次登录的同时 ...

我们有一张「联系人」表，应该与你们的「好友」表性质也类似。你们这种方式属于全量更新，而我们的方式属于增量更新。
具体做法就是本地会保留一个最后更新的时间戳，每次同步好友信息时都会携带这个时间戳。
后端会返回给我们在这个时间戳之后的有更新的好友信息，而不是所有的好友信息，并返回新的时间戳。
首次没有同步过好友信息时，时间戳传0，这种情况才是返回所有的好友信息。

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

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

引用：JackJiang 发表于 2021-09-29 12:27
你的做法是，服务端在更新任何一个用户的任何信息时，同时更新它的时间戳对吧

刚去回顾了旧项目的代码，传递的是版本号而不是时间戳，不过原理是一样的。
服务端负责维护这个版本号，客户端只是保存下来并在同步好友时原样传递。
服务端对该版本号的更新时机，应该是在客户端请求同步好友接口时。
服务端返回了增量的好友信息，更新了版本号，然后随增量的好友信息一起返回给客户端。

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

了解了

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

你们这个同步方法是只管好友有没有增量吗，对于之前的好友的个人信息是否修改不在这里返回。再用另外的接口去获取修改后的个人信息？

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

你们这个同步方法是只处理增量好友吗，无论之前的好友的个人信息是否修改都不在这个方法返回。然后再用另外的接口来处理个人信息修改的情况嘛？

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

那你们这个同步好友的操作，是不是只同步增量的好友。要是之前的好友修改了个人信息之类的，这个同步操作不去处理，而是有另外的操作来同步个人信息的修改

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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