引用：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的消息是无法发送到客户端的。

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

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

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

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

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

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