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

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

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

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

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

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

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

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

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

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

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

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