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

默认
发表评论 17
请教可以使用MQ消息队列中间件做即时通讯系统吗?
ActiveMQ类似的消息队列 可以使用发布-订阅或P2P模式, 可以用于开发即时通讯系统吗, 感觉好像没什么应用, 会有什么缺陷吗?

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

上一篇:请问 ios 有没有http长连接的第三方库下一篇:请教一个Android的图片压缩方案,用于我的IM中

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

推荐方案
评论 17
单纯从技术上看,IM系统的所有数据路径无非就是3种情况:
1)消息从A客户端 -> 经由服务器->再转发给B客户端:即C to S to C;
2)消息从A客户端直发服务端:即C to S;
2)消息从服务器直发A客户端:即S to C。

而消息中间件里的订阅模式:
即生产者推送消息到MQ、再由消费者从MQ读取,理论上是完全可以实现上面所说的3种消息传递路径的,如果要实现IM消息的生产和消费,基本上就是一个用户对应一个队列,而大量用户存在的情况下就是大量的队列产生,而每个队列的消息流转其实很少,试想一个人聊天时能发出多少消息?。

但存在一个问题的:
本身MQ被设计来的目的是处理大量的消息的,也即是通常的应用场景下,不会有多少队列存在,但每个队列每秒都要满负荷处理大量的消息,而假设你来开发MQ中间的话,你也能想到:你最大的优化目标是将每个队列的消息处理吞吐做到最大化,而不应该把处理大量的队列连接、断开、重连这些事情做为MQ存在的意义。

综上:
我的个人意见是,没有行不行,而是合不合适,所以就看你怎么选择了。有的人因为IM系统很小,为了省事或偷懒,也真就是用MQ来实现的,但除非你老板懂技术,不然谁管你。
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
引用:JackJiang 发表于 2017-02-08 15:09
单纯从技术上看,IM系统的所有数据路径无非就是3种情况:
1)消息从A客户端 -> 经由服务器->再转发给B客户 ...

群主回的很详细,学习了
引用:JackJiang 发表于 2017-02-08 15:09
单纯从技术上看,IM系统的所有数据路径无非就是3种情况:
1)消息从A客户端 -> 经由服务器->再转发给B客户 ...

如果用MQ总线做消息中转,用一个发布订阅主题不用为每个用户开队列,这样就不用处理大量队列连接。但有另外一个问题,就是每个节点都要接收相同的消息,承受大量并发。有没有其他消息中转方案?我看了你之前叫我看的文章,没有发现好的架构。
签名: 冒个泡
引用:老衲 发表于 2017-06-01 11:25
如果用MQ总线做消息中转,用一个发布订阅主题不用为每个用户开队列,这样就不用处理大量队列连接。但有另 ...

“每个节点都要接收相同的消息,承受大量并发” 你说的这句是怎么理解的?
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
引用:JackJiang 发表于 2017-06-01 12:01
“每个节点都要接收相同的消息,承受大量并发” 你说的这句是怎么理解的?

“承受大量并发”说错了。我们暂时用MQ做中转了
签名: 冒个泡
引用:JackJiang 发表于 2017-02-08 15:09
单纯从技术上看,IM系统的所有数据路径无非就是3种情况:
1)消息从A客户端 -> 经由服务器->再转发给B客户 ...

可以不用那么细化的 端到端的队列。
把客户端发来的所有请求,封装成业务数据,扔到队列;
同时业务服务器消费队列数据,这样基本上就可以达到通道的吞吐最大化使用了。
1发送消息通道
2推送消息通道
3系统消息通道
引用:Da.du.M_s28iT 发表于 2018-10-19 11:28
可以不用那么细化的 端到端的队列。
把客户端发来的所有请求,封装成业务数据,扔到队列;
同时业务服 ...

楼主的意思,其实是不想单独开发客户端网络通信层,而是直接用MQ的客户端来实现。不知我是否理解错了你的意思
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
引用:JackJiang 发表于 2018-10-19 14:42
楼主的意思,其实是不想单独开发客户端网络通信层,而是直接用MQ的客户端来实现。不知我是否理解错了你的 ...

这样呀,楼主想要绕开自己维护的TCP长连接管理,使用MQ的发布订阅自身的会话存续机制,伪装成即时通讯?
说实话,我也想过这个问题,想用emq来做这个TCP长连接层,只不过总感觉好像太省事了,有些地方控制不住。
引用:Da.du.M_s28iT 发表于 2018-10-19 18:01
这样呀,楼主想要绕开自己维护的TCP长连接管理,使用MQ的发布订阅自身的会话存续机制,伪装成即时通讯?
...

是的,适用场景不一样,MQ也不是一个放之四海而皆准的万能钥匙
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
一个队列占用不了多少系统资源吧,和list不是一样么
签名: 愉快的一天。
引用:inrg 发表于 2019-03-09 16:47
一个队列占用不了多少系统资源吧,和list不是一样么

队列只是表象了,其实归根到底,一个系统是有适用场景的问题,你非要那样用当然也可以用,就像当初XMPP设计者们从未考虑过移动端会有这么流行的那一天,扫以xmpp设计之初压根就没有考虑过省流量这种事。道理就是这样。
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
引用:JackJiang 发表于 2019-03-10 17:38
队列只是表象了,其实归根到底,一个系统是有适用场景的问题,你非要那样用当然也可以用,就像当初XMPP设 ...

您好,想问个问题,类似抖音推送的功能您认为他是怎么实现的
引用:programmerhjh 发表于 2019-04-16 19:11
您好,想问个问题,类似抖音推送的功能您认为他是怎么实现的

什么样的推送,截个图看看
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
引用:JackJiang 发表于 2019-04-16 19:28
什么样的推送,截个图看看

2.jpg 1.jpg
就像这样子,每个用户你上来就从推送队列拉取出队一个推荐的视频,下拉就推荐队列再次出队,抛开推荐算法的设计,您以为这个架构设计大致是如何的,还是依然是那种一个用户一个推荐队列这种方式吗?
引用:programmerhjh 发表于 2019-04-16 20:08
就像这样子,每个用户你上来就从推送队列拉取出队一个推荐的视频,下拉就推荐队列再次出队,抛开推荐算 ...

不可能一个用户一个推荐队列了。肯定是先对用户进行画像分类,然后每个分类有一些算法预推荐的视频都准备好了,要推关时随时在它的分类里取一种就好了
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
引用:JackJiang 发表于 2019-04-16 20:14
不可能一个用户一个推荐队列了。肯定是先对用户进行画像分类,然后每个分类有一些算法预推荐的视频都准备 ...

感谢回答,不过请问还能再具体点吗,比如就是分类和取的时候要用什么中间件呢
引用:programmerhjh 发表于 2019-04-16 23:56
感谢回答,不过请问还能再具体点吗,比如就是分类和取的时候要用什么中间件呢

我只是基于常识分析的,因为我没有这样的需求,所以没亲自实践过,不能误导你了。你最好查一下更多的资料
签名: 《微信红包系统的存储层架构演进实践》:http://www.52im.net/thread-2568-1-1.html
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部