请选择 进入手机版 | 继续访问电脑版

默认
发表评论 12
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
基于MobileIMSDK的IM每天几千离线消息,群聊会话列表、离线拉取问题
根据文章《IM开发干货分享:如何优雅的实现大量离线消息的可靠投递》这个。实现群聊消息会话列表的时候的问题。

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

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


即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

标签:求助 IM开发
上一篇:[已回复] 求教基于MobileIMSDK的iOS端networkStatusObserver 为nil的问题下一篇:[已回复] 求教MobileIMSDK服务端onTransferMessage4C2S如何处理异常?消息已ack?

本帖已收录至以下技术专辑

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

另外:如果你是富客户端,有本地缓存的话,这个所谓的会话列表放本地维护简单合理,为什么要放服务端维护
签名: 不开心,不快乐
引用:JackJiang 发表于 2022-06-08 10:16
先不说方案合不合理,“写500次redis还是非常耗时的啊。要不断的get,set。差不多1000次。耗时都要500ms了 ...

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

怎么放本地?比如消息的未读数,最后一条消息等,客户端都离线了。怎么知道这些变化。不是客户端上线后才同步这些变化吗
引用: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
引用:li709854423 发表于 2022-06-08 10:29
redis的性能或许可以提高。但是中间的序列化也要时间啊。json的序列化反序列化。刚刚换了个序列化框架。5 ...

当然是上线同步了,不然这会话列表给谁看呢
签名: 不开心,不快乐
引用:li709854423 发表于 2022-06-08 10:35
如果写一份redis,不是每个用户写一份, groupId:lastUpdateTime+context  这样。然后用户上线后,拿本地 ...

你服务端维护未读数,我觉得搞复杂了,微信也是本地实现的啊
签名: 不开心,不快乐
引用:JackJiang 发表于 2022-06-08 11:14
你服务端维护未读数,我觉得搞复杂了,微信也是本地实现的啊

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

其实我是不赞成服务端处理的,我支持按微信的方法处理,简单直接,这样做,甚至后面能比较容易做到微信已读指令的多端同步
签名: 不开心,不快乐
引用:JackJiang 发表于 2022-06-08 12:20
其实我是不赞成服务端处理的,我支持按微信的方法处理,简单直接,这样做,甚至后面能比较容易做到微信已 ...

这里就是要看到我做的项目。是每个群只要离线一天。就几千条消息。。我的场景就是这样的。。上线要拉取太多的群消息了啊可咋整,客户端得卡死
引用:li709854423 发表于 2022-06-08 14:18
这里就是要看到我做的项目。是每个群只要离线一天。就几千条消息。。我的场景就是这样的。。上线要拉取太 ...

你这消息的活跃度比微信大多了,可能真得特殊场景特殊考虑了,离线数据多是事实,用户不可能全部看这些数据也是事实,可以制度数据丢充策略,或者分页拉取策略(登陆时只拉取少量页数的数据,以及全部未读数据)
签名: 不开心,不快乐
引用:JackJiang 发表于 2022-06-08 15:04
你这消息的活跃度比微信大多了,可能真得特殊场景特殊考虑了,离线数据多是事实,用户不可能全部看这些数 ...

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

实时发出的群消息都是扩散写,相当于是新的fp了。但它可以带上原消息的fp,原消息的fp可以在实现消息撤回功能里使用
签名: 不开心,不快乐
好文章,支持!
签名: 今天很666
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部