求教IM历史聊天消息的存储如何满足多端同步的场景

前言：公司使用mongodb存储全量历史消息，主要分为消息表t_message[msg_id],和用户同步表t_user_message[user_uuid,msg_id,source_device,seq]。例如用户a给用户b发送一条消息，会在t_message存储消息原文产生一条数据，同时在t_user_message保存2条消息，其中用户a会记录source_device，例如app、pc、web等，查询用户离线消息的逻辑是  where user_uuid = #user_uuid and seq > #seq and source_device != #source_device，假设此时用户a是app发送的，会同步给非app登录的其他设备。

以上方案虽然逻辑上没问题，但是感觉不能很好的利用mongodb的索引，有没有更好的存储设计，小弟跪谢！

我觉得你要跳出复杂的逻辑，可以考虑用时间来实现多端消息的增量拉取。就是不管哪个端，本地取最新一条消息的时间，然后跟服务端全量消息比对，取出此时间之后的全部消息就是本次需要同步的消息。

这种逻辑最精简优雅，但可能存在因极端情况下的某些异步必致消息漏掉或重复，这些异常你要处理好，那就是个不错的方案

引用：JackJiang 发表于 2023-02-01 10:46
我觉得你要跳出复杂的逻辑，可以考虑用时间来实现多端消息的增量拉取。就是不管哪个端，本地取最新一条消息 ...

如果使用时间同步，本地取最新一条消息的时间，这个最新一条消息包括自己发送的的消息吗？
如果不包括，网络重连，个人觉得会重复拉取自己已发送的无意义消息；
如果包括，最后一条消息之前时间收到的离线消息未同步完成直接使用新的时间去同步，会漏掉之前的部分消息。感觉这样处理消息服务的可靠性很难保证

引用：test_forever 发表于 2023-02-01 13:58
如果使用时间同步，本地取最新一条消息的时间，这个最新一条消息包括自己发送的的消息吗？
如果不包括， ...

对，按时间比对增量就是这些问题处理起来比较棘手，但对于整体的逻辑来说，这个方案是最简单直接的

引用：JackJiang 发表于 2023-02-01 19:16
对，按时间比对增量就是这些问题处理起来比较棘手，但对于整体的逻辑来说，这个方案是最简单直接的

有没有可能根据用户的uuid作为消息广播的一个组，任何端在建立连接的时候可以订阅这个组，发送消息时向组中的所有连接进行广播？

引用：1Nsulate 发表于 2023-02-02 10:33
有没有可能根据用户的uuid作为消息广播的一个组，任何端在建立连接的时候可以订阅这个组，发送消息时向组 ...

你终于想到这个了，你可以百度搜一下Actor分布式模型，以及Actor模型的Java实现Akka，仔细研究一下

引用：JackJiang 发表于 2023-02-02 11:21
你终于想到这个了，你可以百度搜一下Actor分布式模型，以及Actor模型的Java实现Akka，仔细研究一下

咱们这有相关文章么？大佬您分享的文章都特别好，不知道这里有没有

引用：1Nsulate 发表于 2023-02-02 17:37
咱们这有相关文章么？大佬您分享的文章都特别好，不知道这里有没有

暂时没有关于im的这个专门的文章

引用：JackJiang 发表于 2023-02-02 11:21
你终于想到这个了，你可以百度搜一下Actor分布式模型，以及Actor模型的Java实现Akka，仔细研究一下

其实我们的消息投放逻辑是先持久化db再异步转发消息，为了不丢消息，消息必须是从db或者缓存层读取，我主要困惑的是如何在满足多端同步的情况下还能提高读取db的性能。