上面的存在一個問題是，在普通的聊天場景中，爲了進行精準投遞避免資源浪費，一般會維護一箇中央的在線狀態，在邏輯層在確定好投遞的接收人後，通過這個在線狀態查詢對應接收人所在的網關機，然後只需要把消息投遞給這臺網關機就好了。
但是對於直播互動場景來說，對於這個精準投遞應該如何進行優化呢？
首先，每一臺網關機在啓動時會訂閱一個全局的消息隊列；當用戶進入直播間後，會在每臺網關機的本機維護一個在線狀態；同樣的，假設這時用戶A發送了彈幕消息，這條消息會在業務邏輯處理層進行處理；緊接着再由業務處理層給剛纔網關機訂閱的全局的消息隊列，這樣所有網關機都能收到消息；最後，每臺網關機根據本機維護的某個直播間在線用戶，再把消息下推給用戶設備。
服務拆分
自動擴容縮容
對於直播互動場景中的監控指標一般可以分爲兩大類：
業務性能指標：比如直播間人數，發消息和信令的QPS與耗時，消息收發延遲等
機器性能指標：主要是通用化的機器性能指標，包括帶寬，PPS，系統負載，IOPS
智能負載均衡
對於直播互動的消息下推來說，長連接入服務維護了房間和用戶的長連接，那麼這裏的問題在於：擴容前的機器已經存在的長連接可能已經處於高水位狀態，新擴容的機器卻沒有承載用戶連接，而對於長連接入服務前端的負載均衡層來說，大部分都採用普通的輪詢，並不管後端的長連接入機器是否已經承載了很多連接，這樣會導致後續的新的連接請求還是均勻地分配到舊機器和新機器上，導致舊機器過早達到瓶頸，而新機器沒有被充分利用。
在這種情況下，即使是讓負載均衡層支持自定義的複雜的均衡算法，也可能無法解決流量不平衡的問題。因爲很多情況下，負載均衡層本身也是需要擴容的，自定義的均衡算法也只能在某一臺負載均衡機器上失效，無法真正做到全局的調度和均衡。
一個更好的方案是接管用戶連接的入口，在最外層入口來進行全局調度。
比如，在建立長連接前，客戶端先通過一個入口調度服務來查詢背刺連接應該連接的入口IP，在這個入口調度服務里根據具體後端接入層機器的具體業務和機器的性能指標，來實時計算調度的權重。負載低的機器權重值高，會被入口調度服務作爲優先接入IP下發；負載高的機器權重值低，後續新的連接接入會相對更少。
