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

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

引用：榴莲与狗 发表于 2020-01-29 21:41
好的，这么看来就没必要改造了，因为单从实时性来讲长连接做转发就比mq要快了，谢谢

关键是你的思路里，mq很容易成为单点瓶颈，达不到分布式无限扩展的要求。

引用：JackJiang 发表于 2020-01-29 21:30
做分布式的话，im这种长连接应用为了效率，服务端最高效的方式也就是与相关节点进行一对一长连接。长连接 ...

好的，这么看来就没必要改造了，因为单从实时性来讲长连接做转发就比mq要快了，谢谢

引用：榴莲与狗 发表于 2020-01-29 21:05
群主真的很有耐心解答的问题呢，完全的谦卑心态，性格真的很好，看了你很多文章，很多观点我都很认同，也 ...

做分布式的话，im这种长连接应用为了效率，服务端最高效的方式也就是与相关节点进行一对一长连接。长连接就是这样，只能硬连，没有更好的办法。但每个实例的生命周期，你可以用ZooKeeper来管理，不然自已来写的话，那就很复杂了。基本上，当你的当前实例需要跟连接对应的其它服务端实例时才连接，并保存持这个连接即可。总的来说，算法封装好的话，有了ZooKeeper的协助，复杂性可以大大降低，而且后面的高可用，实现起来也可以很透明优雅。

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

群主真的很有耐心解答的问题呢，完全的谦卑心态，性格真的很好，看了你很多文章，很多观点我都很认同，也学习到了很多知识。无意中发现这个网站，最近也在做im，有种相见恨晚的感觉。另外对于这个疑问我之前也有考虑过，我们im是分布式的，s是多台，通过网关转发的，s-s直接是基于tcp长连接做的，这样的话假设我有10台机器那么他们直接的关系是很复杂的，s1（其实是每个s）要和其他9台服务器保持长连接，我之前也考虑过通过mq来处理，topic就是服务的ip这样子，我要转发到哪个机器就发到哪个topic，没有实践，但是我想到会有一个问题，如果按照ip去设置topic,当用户断线重连之后从s1连接到了s2网关，那么之前那个s1的消息是无法发送到客户端的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

引用：Da.du.M_s28iT 发表于 2018-10-19 11:28
可以不用那么细化的 端到端的队列。
把客户端发来的所有请求，封装成业务数据，扔到队列；
同时业务服 ...

楼主的意思，其实是不想单独开发客户端网络通信层，而是直接用MQ的客户端来实现。不知我是否理解错了你的意思

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

可以不用那么细化的 端到端的队列。
把客户端发来的所有请求，封装成业务数据，扔到队列；
同时业务服务器消费队列数据，这样基本上就可以达到通道的吞吐最大化使用了。
1发送消息通道
2推送消息通道
3系统消息通道

引用：JackJiang 发表于 2017-06-01 12:01
“每个节点都要接收相同的消息，承受大量并发” 你说的这句是怎么理解的？

“承受大量并发”说错了。我们暂时用MQ做中转了