netty 路由发消息通过http服务实现，性能怎么样

[mushang8923]

通过tomcat实现的http服务发送消息，线程过多的话会不会对netty服务器的io有影响 是否有其他更好的解决方案 譬如，在netty服务端起一个消息消费的客户端，所有的要发的路由消息，放到mq中，由mq统一管理，这种否可行

[crossoverJie]

通过tomcat实现的http服务发送消息，线程过多的话会不会对netty服务器的io有影响

过多肯定都是有影响的，在一个 JVM 中线程过多导致的上下文切换对整个应用都有影响（并不只是现在的 IM 场景）；不过我觉得在这里并不是问题。

• Tomcat 可以配置线程池上限。
• 在任何 web 应用中 Tomcat 线程都是和其他线程合在一起的，很少有案例表明 Tomcat 会影响其他业务。

譬如，在netty服务端起一个消息消费的客户端，所有的要发的路由消息，放到mq中，由mq统一管理，这种否可行

MQ 更多的目的还是为了削峰限流以及异步为目的，在 IM 实时通讯的场景我觉得并不适用，消息通常都是要求实时性，一旦使用 MQ 便失去本身的目的了。

[mushang8923]

我还有一个疑问： 1.节点管理，将ip和端口暴露出去，安全有考虑吗 2.针对分布式的route，如何保证，如果按轮询策略返回服务器，如何保证全局的轮询 3.一个新的服务节点起来以后，是否要做预热

[crossoverJie]

1. Nginx 现在好像也支持 TCP 长连接的反向代理了，我还没试过；在我们的实践中对客户端的接入及消息的发送都加上了鉴权，已经可以去除大部分的恶意连接（话说服务器的 80 端口也是暴露出去的）。
2. 如果要全局轮询只能每次都从公共内存中获取节点信息（比如 Redis），但这样本地缓存也就没用了。
3. 这里的预热是指预热什么？

[mushang8923]

nginx是可以做tcp的长连接代理的，只是不知道nginx是否会想http一样流量要经过它（tcp长连接的没有验证过）。如果流量要经过它，就容易受带宽的限制 我打算做一个最少连接数的控制策略，然后通过redis的发布订阅模式，跟zk比较像，变化了再修改数据，然后本地缓存一样可以用，只是信息如果不做全局锁可能不太准。但是应该没太大关系吧？ 预热指的是服务节点刚进来的时候，控制连接进来的速度，就是跟dubbo的节点预热一样的

[happytonny]

我们是通过MQ进行转发的，每个IM-Server 分配一个队列，维护一个session和队列的对应关系，每个IM-server在向client发消息时是通过mq获得要发送的消息

[JackJiang2011]

我们是通过MQ进行转发的，每个IM-Server 分配一个队列，维护一个session和队列的对应关系，每个IM-server在向client发消息时是通过mq获得要发送的消息

MQ不就成了单点瓶颈了？