请教可以使用MQ消息队列中间件做即时通讯系统吗？

ActiveMQ类似的消息队列 可以使用发布-订阅或P2P模式, 可以用于开发即时通讯系统吗, 感觉好像没什么应用, 会有什么缺陷吗?

单纯从技术上看，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来实现的，但除非你老板懂技术，不然谁管你。

引用：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总线做消息中转，用一个发布订阅主题不用为每个用户开队列，这样就不用处理大量队列连接。但有另 ...

“每个节点都要接收相同的消息，承受大量并发” 你说的这句是怎么理解的？

引用：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的客户端来实现。不知我是否理解错了你的意思

引用：JackJiang 发表于 2018-10-19 14:42
楼主的意思，其实是不想单独开发客户端网络通信层，而是直接用MQ的客户端来实现。不知我是否理解错了你的 ...

这样呀，楼主想要绕开自己维护的TCP长连接管理，使用MQ的发布订阅自身的会话存续机制，伪装成即时通讯？
说实话，我也想过这个问题，想用emq来做这个TCP长连接层，只不过总感觉好像太省事了，有些地方控制不住。

引用：Da.du.M_s28iT 发表于 2018-10-19 18:01
这样呀，楼主想要绕开自己维护的TCP长连接管理，使用MQ的发布订阅自身的会话存续机制，伪装成即时通讯？
...

是的，适用场景不一样，MQ也不是一个放之四海而皆准的万能钥匙

一个队列占用不了多少系统资源吧，和list不是一样么

引用：inrg 发表于 2019-03-09 16:47
一个队列占用不了多少系统资源吧，和list不是一样么

队列只是表象了，其实归根到底，一个系统是有适用场景的问题，你非要那样用当然也可以用，就像当初XMPP设计者们从未考虑过移动端会有这么流行的那一天，扫以xmpp设计之初压根就没有考虑过省流量这种事。道理就是这样。

引用：JackJiang 发表于 2019-03-10 17:38
队列只是表象了，其实归根到底，一个系统是有适用场景的问题，你非要那样用当然也可以用，就像当初XMPP设 ...

您好，想问个问题，类似抖音推送的功能您认为他是怎么实现的

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

什么样的推送，截个图看看

引用：JackJiang 发表于 2019-04-16 19:28
什么样的推送，截个图看看

就像这样子，每个用户你上来就从推送队列拉取出队一个推荐的视频，下拉就推荐队列再次出队，抛开推荐算法的设计，您以为这个架构设计大致是如何的，还是依然是那种一个用户一个推荐队列这种方式吗？

引用：programmerhjh 发表于 2019-04-16 20:08
就像这样子，每个用户你上来就从推送队列拉取出队一个推荐的视频，下拉就推荐队列再次出队，抛开推荐算 ...

不可能一个用户一个推荐队列了。肯定是先对用户进行画像分类，然后每个分类有一些算法预推荐的视频都准备好了，要推关时随时在它的分类里取一种就好了

引用：JackJiang 发表于 2019-04-16 20:14
不可能一个用户一个推荐队列了。肯定是先对用户进行画像分类，然后每个分类有一些算法预推荐的视频都准备 ...

感谢回答，不过请问还能再具体点吗，比如就是分类和取的时候要用什么中间件呢

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

我只是基于常识分析的，因为我没有这样的需求，所以没亲自实践过，不能误导你了。你最好查一下更多的资料

您好，我最近也遇到这么个问题，是否使用MQ做服务器内部的消息中转，还是直接发送消息？
关于服务器内部的消息中转，我目前使用队列的版本是这样做的：
client-a 发送一个消息到服务器，服务器将其投递给client-b的消息队列，b从队列中收到消息后使用tcp写给客户端。
本质上，我是把mq当成客户端的同步队列使用了，使用消息队列来确保消息的顺序。如果不用mq，这一块也许还可以用存储来实现，然后顺序保证依赖底层数据库？
但是使用mq，则顺序机制过度依赖于使用的mq提供的机制是否支持，以及支持程度，扩展性并不好。
且看到群主的第一个回复，确实为每个用户维护一个mq有点奢侈。那如果不用mq，则是用db存储或者其他之类的作同步 队列么？

引用：bakatora 发表于 2020-01-10 02:03
您好，我最近也遇到这么个问题，是否使用MQ做服务器内部的消息中转，还是直接发送消息？
关于服务器内部的 ...

其实对于im服务端来说，高并发和严格的顺序保证，是个矛盾体，要做高并发，肯定就很难在服务端保证顺序，其实顺序主要影响的是用户看到的内容，可以多在客户端做做文章，尽可能减轻服务端的逻辑复杂性和压力，必竟服务端越搞越复杂，以后的扩展成本就越来越高，可扩展性也越来越差。