默认
发表评论 3
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
IM场景蓝绿发布问题,以及用户共享问题(主要是群聊)
阅读(274) | 评论(3 收藏1 淘帖 1
大家好:
        有几个问题还望大家解疑。
        目前我们即时通讯的场景是这样,首先我们是集群部署,我们将用户再建立长链接之前会先调用http接口,此接口会将用户ID进行hash 取模计算出该用户应该连接到哪台服务节点,返回给客户端长链接地址(不用节点的长链接地址不一致)。
建立连接后会将连接信息存放在本地。(通道信息无共享)以上是前提。
        我们如果要向群聊中发送消息时,我们会通过所有用户ID进行hash 取模(和建立连接时算法保持一致)计算出连接的哪台服务器,然后使用rpc分发给不同节点。
       现在我们要做蓝绿发布,我们的计划方案是:想要把通道共享,再用户建立连接时,将用户连接的节点信息存放在redis/MongoDB中。向群聊中发送消息时会把群聊中所有用户通过redis/MongoDB查到节点信息,进行rpc分发。
我们真实使用场景可能会有1000人的大群,那么每次发送一条消息就需要查1000次redis,体量很大。
我想问的问题是:
1、对于蓝绿发布我们将长链接通道同享存放在redis中,是否可行,是否您这边还有更优方案。
2、如果共享通道信息,那么在大群中发送消息就需要频繁查询redis,是否还有其他机制呢。

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

标签:求助 IM开发
上一篇:求教关于IM中消息id是客户端还是服务端生成的问题
推荐方案
评论 3
我觉得你的明显问题是“每次发送一条消息就需要查1000次redis”。

能否优化一下redis中的key逻辑,想办法用一次redis查询,取出该群的所有人的连接信息,而不是每人都要查一次,那确实不够优秀
引用:JackJiang 发表于 2024-09-13 11:15
我觉得你的明显问题是“每次发送一条消息就需要查1000次redis”。

能否优化一下redis中的key逻辑,想办 ...

感谢您的回答,如果说我们设计将长链接信息存储在redis没有问题的话,考虑了觉得redis 的key还是以用户标识通用性比较高,那我们就考虑使用redis mget进行批量查询。您觉得呢。
引用:18334556780 发表于 2024-09-13 14:07
感谢您的回答,如果说我们设计将长链接信息存储在redis没有问题的话,考虑了觉得redis 的key还是以用户标 ...

搞im集群也差不多都是这样的逻辑,没有别的更好的捷径
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部