基于MobileIMSDK的IM每天几千离线消息，群聊会话列表、离线拉取问题

根据文章《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》这个。实现群聊消息会话列表的时候的问题。

如果发送一条群消息。群里有500个人离线。
那就需要后端更新500个人的最后一条消息的内容和日期，以便离线用户登陆时。拉取会话列表的时候知道该群消息更新了。
那写500次redis还是非常耗时的啊。要不断的get，set。差不多1000次。耗时都要500ms了。

如果500个人的会话列表后端不维护更新。只要写一条群ID+最后消息时间的redis记录。只操作一次。就可以节省时间了。
但是这样离线用户登陆时，假设本地会话列表有5个群。这5个群ID上传后端。后端匹配redis后找到对应一条群ID的redis记录的。返回有更新是可以的。
但是如果假设本地会话列表有5个。但是实际上有6个群的消息有更新，因为没有每个用户都单独写redis会话列表更新，后端是不知道还多一个群的。这时候怎么处理呢？

引用：li709854423 发表于 2022-06-08 15:13
所以现在就是登陆时只拉取会话信息的最新内容啊。。所以才会遇到发帖问遇到的问题。现在我优化后用了批处 ...

实时发出的群消息都是扩散写，相当于是新的fp了。但它可以带上原消息的fp，原消息的fp可以在实现消息撤回功能里使用

引用：JackJiang 发表于 2022-06-08 15:04
你这消息的活跃度比微信大多了，可能真得特殊场景特殊考虑了，离线数据多是事实，用户不可能全部看这些数 ...

所以现在就是登陆时只拉取会话信息的最新内容啊。。所以才会遇到发帖问遇到的问题。现在我优化后用了批处理的redis，批量读取更新500个人的会话信息。大概40ms。似乎是可以接受的了。但我才发现。因为qos是没做到群这块的。。群这块的QOS是怎么保证的？
客户端C2S后。服务端就QOS回去已经收到群消息？接下来怎么做？假设有20人。5个在线15个离线，那给5个在线的发消息？每个消息的FP=都重新算一遍？还是要重新设计QoS4SendDaemonS2C

引用：li709854423 发表于 2022-06-08 14:18
这里就是要看到我做的项目。是每个群只要离线一天。就几千条消息。。我的场景就是这样的。。上线要拉取太 ...

你这消息的活跃度比微信大多了，可能真得特殊场景特殊考虑了，离线数据多是事实，用户不可能全部看这些数据也是事实，可以制度数据丢充策略，或者分页拉取策略（登陆时只拉取少量页数的数据，以及全部未读数据）

引用：JackJiang 发表于 2022-06-08 12:20
其实我是不赞成服务端处理的，我支持按微信的方法处理，简单直接，这样做，甚至后面能比较容易做到微信已 ...

这里就是要看到我做的项目。是每个群只要离线一天。就几千条消息。。我的场景就是这样的。。上线要拉取太多的群消息了啊可咋整，客户端得卡死

引用：li709854423 发表于 2022-06-08 11:34
...微信是采用全量消息推送。所以本地能实现未读数啊。
我参考的那个文章。他采用的是按需拉取啊。所以 ...

其实我是不赞成服务端处理的，我支持按微信的方法处理，简单直接，这样做，甚至后面能比较容易做到微信已读指令的多端同步

引用：JackJiang 发表于 2022-06-08 11:14
你服务端维护未读数，我觉得搞复杂了，微信也是本地实现的啊

...微信是采用全量消息推送。所以本地能实现未读数啊。
我参考的那个文章。他采用的是按需拉取啊。所以要服务端维护未读数啊。
redis我看好像是可以用批处理的。我试试批处理几百条数据的。似乎可以大量节省时间

引用：li709854423 发表于 2022-06-08 10:35
如果写一份redis,不是每个用户写一份， groupId:lastUpdateTime+context  这样。然后用户上线后，拿本地 ...

你服务端维护未读数，我觉得搞复杂了，微信也是本地实现的啊

引用：li709854423 发表于 2022-06-08 10:29
redis的性能或许可以提高。但是中间的序列化也要时间啊。json的序列化反序列化。刚刚换了个序列化框架。5 ...

当然是上线同步了，不然这会话列表给谁看呢

引用：JackJiang 发表于 2022-06-08 10:16
先不说方案合不合理，“写500次redis还是非常耗时的啊。要不断的get，set。差不多1000次。耗时都要500ms了 ...

如果写一份redis,不是每个用户写一份， groupId:lastUpdateTime+context  这样。然后用户上线后，拿本地的会话列表对比，知道有更新。那还需要去找数据库，找到更新区间的未读数，感觉这样效率也很差。用户如果会话列表的群非常多，那上线后多个群有更新，每个更新的群都要查一次未读数。
如果写多份reids,那就是 memberId:groupId:lastUpdateTime+context+未读数，这样用户上线后就那本地的会话列表比较后。不用查库 ，就可以拿到所有需要的数据。但是写多份我刚测完的确实是需要200多ms，500读,500写，因为序列化和反序列化json需要时间啊。。或许我改成多线程序列化可以加快点速度？
就是想知道一条离线消息被这样处理多久是比较合理的？按多份的话？目前写一份的情况下。一条500人的群消息处理只要十几ms

引用：JackJiang 发表于 2022-06-08 10:16
先不说方案合不合理，“写500次redis还是非常耗时的啊。要不断的get，set。差不多1000次。耗时都要500ms了 ...

redis的性能或许可以提高。但是中间的序列化也要时间啊。json的序列化反序列化。刚刚换了个序列化框架。500次读500次写redis也是耗时200多了。继续换更快的框架感觉只要100多都挺多的。

怎么放本地？比如消息的未读数，最后一条消息等，客户端都离线了。怎么知道这些变化。不是客户端上线后才同步这些变化吗

先不说方案合不合理，“写500次redis还是非常耗时的啊。要不断的get，set。差不多1000次。耗时都要500ms了。”，按照redis 的更新策略“业务type: groupId: memberId: lastUpdateTime”，这样更新肯定用不了500ms，你可以自已测试一下，redis的性能远不是你想的传统的那样

另外：如果你是富客户端，有本地缓存的话，这个所谓的会话列表放本地维护简单合理，为什么要放服务端维护