公司IM后台离线消息采用扩散写，导致redis内存爆掉，不合理，求指点

如题，目前公司im项目遇到一个瓶颈问题。离线消息量大了，导致服务器内存吃紧（因为这个问题爆了两次了），（目前是离线消息存在redis里边）。

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

求助各位大佬指点。

你这群聊的离线消息是用扩散写的方式实现的，这很耗资源。
建议改成扩散读，可以详细读一下这篇《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》

群聊人数多的情况下, 离线消息就多, 一下子人1条变2000条，想想都阔怕啊..... 肯定不是这样玩

如果采用读扩散，拉取消息的逻辑就比较复杂了，之前公司采用读扩散，最终改成了写扩散，但还没有大群。
你这种情况是否可以写扩散的时候只扩散消息ID，消息本身存一份，查询的时候先查id，在根据id查消息，如果是数据库查询就级联查询，表结构大概是 userId，msgId，另一张表是mgsId，消息的其他字段。单聊消息同样这样处理。是否可行？

引用：liupf 发表于 2020-08-03 09:40
如果采用读扩散，拉取消息的逻辑就比较复杂了，之前公司采用读扩散，最终改成了写扩散，但还没有大群。
你 ...

写扩散逻辑简单直接，但缺点就是需要更多的存储空间。读扩散除了优点是省存储空间以外，没什么优势。这两种方式，就看用户量多少，以及对存储空间的敏感性了。

读扩散拉取逻辑确实太复杂了，比如如果我又50个群，那要一个个拉，效率太低了；
写扩散拉取简单，但是问题是，要先写群消息表，然后再写每个群用户的接收消息表，如何保证写入操作的原子性，比如写群消息表成功了，但是写每个用户的接收消息表却失败了，那是不是群用户就拉不到该条消息了？那就丢消息了。。。

引用：hangp 发表于 2020-08-24 09:47
读扩散拉取逻辑确实太复杂了，比如如果我又50个群，那要一个个拉，效率太低了；
写扩散拉取简单，但是问题 ...

存表，存缓存，两重保障呢