上面的存在一个问题是，在普通的聊天场景中，为了进行精准投递避免资源浪费，一般会维护一个中央的在线状态，在逻辑层在确定好投递的接收人后，通过这个在线状态查询对应接收人所在的网关机，然后只需要把消息投递给这台网关机就好了。
但是对于直播互动场景来说，对于这个精准投递应该如何进行优化呢？
首先，每一台网关机在启动时会订阅一个全局的消息队列；当用户进入直播间后，会在每台网关机的本机维护一个在线状态；同样的，假设这时用户A发送了弹幕消息，这条消息会在业务逻辑处理层进行处理；紧接着再由业务处理层给刚才网关机订阅的全局的消息队列，这样所有网关机都能收到消息；最后，每台网关机根据本机维护的某个直播间在线用户，再把消息下推给用户设备。
服务拆分
自动扩容缩容
对于直播互动场景中的监控指标一般可以分为两大类：
业务性能指标：比如直播间人数，发消息和信令的QPS与耗时，消息收发延迟等
机器性能指标：主要是通用化的机器性能指标，包括带宽，PPS，系统负载，IOPS
智能负载均衡
对于直播互动的消息下推来说，长连接入服务维护了房间和用户的长连接，那么这里的问题在于：扩容前的机器已经存在的长连接可能已经处于高水位状态，新扩容的机器却没有承载用户连接，而对于长连接入服务前端的负载均衡层来说，大部分都采用普通的轮询，并不管后端的长连接入机器是否已经承载了很多连接，这样会导致后续的新的连接请求还是均匀地分配到旧机器和新机器上，导致旧机器过早达到瓶颈，而新机器没有被充分利用。
在这种情况下，即使是让负载均衡层支持自定义的复杂的均衡算法，也可能无法解决流量不平衡的问题。因为很多情况下，负载均衡层本身也是需要扩容的，自定义的均衡算法也只能在某一台负载均衡机器上失效，无法真正做到全局的调度和均衡。
一个更好的方案是接管用户连接的入口，在最外层入口来进行全局调度。
比如，在建立长连接前，客户端先通过一个入口调度服务来查询背刺连接应该连接的入口IP，在这个入口调度服务里根据具体后端接入层机器的具体业务和机器的性能指标，来实时计算调度的权重。负载低的机器权重值高，会被入口调度服务作为优先接入IP下发；负载高的机器权重值低，后续新的连接接入会相对更少。
