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

默认
发表评论 4
公司IM后台离线消息采用扩散写,导致redis内存爆掉,不合理,求指点
如题,目前公司im项目遇到一个瓶颈问题。离线消息量大了,导致服务器内存吃紧(因为这个问题爆了两次了),(目前是离线消息存在redis里边)。

接着修改存入数据库中,但是问题又来了,一个500人的群,发一条消息就存入499条离线消息,感觉不太合理。

求助各位大佬指点。


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

上一篇:IM中三次失败重传用完,对方已收到,而我方没收到ACK应答怎么办?下一篇:IM系统开发中,在线消息推送失败后一般怎么处理?

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

想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
推荐方案
评论 4
你这群聊的离线消息是用扩散写的方式实现的,这很耗资源。
建议改成扩散读,可以详细读一下这篇《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?》
签名: 《如何让你的WebSocket断网重连更快速?》http://www.52im.net/thread-3098-1-1.html
群聊人数多的情况下, 离线消息就多, 一下子人1条变2000条,想想都阔怕啊..... 肯定不是这样玩
如果采用读扩散,拉取消息的逻辑就比较复杂了,之前公司采用读扩散,最终改成了写扩散,但还没有大群。
你这种情况是否可以写扩散的时候只扩散消息ID,消息本身存一份,查询的时候先查id,在根据id查消息,如果是数据库查询就级联查询,表结构大概是 userId,msgId,另一张表是mgsId,消息的其他字段。单聊消息同样这样处理。是否可行?
引用:liupf 发表于 2020-08-03 09:40
如果采用读扩散,拉取消息的逻辑就比较复杂了,之前公司采用读扩散,最终改成了写扩散,但还没有大群。
你 ...

写扩散逻辑简单直接,但缺点就是需要更多的存储空间。读扩散除了优点是省存储空间以外,没什么优势。这两种方式,就看用户量多少,以及对存储空间的敏感性了。
签名: 《如何让你的WebSocket断网重连更快速?》http://www.52im.net/thread-3098-1-1.html
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部