移動應用軟件有一些是長連接的，而服務器端的集羣部署，有的是通過F5把每一次網絡請求隨機轉發到集羣中某一臺應用服務器上的。要是想把某消息通過集羣環境發送到移動端，那麼集羣中網絡請求的隨機轉發與移動端長連接的特性會有矛盾。
本文以Androidpn（網絡協議爲XMPP）爲例，介紹一種後臺集羣部署解決移動端與服務器間長連接問題的方法。
網絡連接示意圖：
(上圖省去了APN服務器與IME客戶端之間的網絡層)
網絡消息路由:F5～APN(x):外部的網絡請求，會隨機發送到集羣中的一臺APN服務器上。XMPP消息路由：APN01~IME01, APN(x)~IME(x):設備(x)只與一臺服務器APN(x)保持長連接，是一一對應的關係。
舉例說明集羣遇到的問題：
假如APN01與IMEO1保持連接。當有外部網絡請求、要向IME01發送消息時，F5首先接到網絡請求，並將此請求隨機轉發給APN服務器，可能是APN02。而此時APN02服務器與IME01沒有連接，此請求就無法發送出去了。
解決方法：
引入Rabbitmq 消息中間件 ，用於APN服務器間的消息轉發、通信。每一臺APN服務器，通過rabbitmq客戶端與rabbitmq服務器進行通信。
引入Memcache存服務器 ，勝於長連接客戶端面與服務器的字典表，每次移動端登陸服務器應用時，就把移動端標識與其連接的服務器標識保存在緩存。每一臺APN服務器通過MemCache客戶端與MemCache服務器進行通信。
接着上一個假設中的問題，APN02在接收到網絡請求時，首先拿通過MemCache查詢該移動端連接的APN服務器是哪個(MemCache中記錄APN01與IMEO1保持連接)，若是本機則處理消息，否則就將網絡請求的消息發送到Rabbitmq服務器（rabbitmq路由機制及設計方法不是本文的重點），Rabbitmq服務器根據路由，將消息發送給與IMEO1保持連接的APN01服務器上的Rabbitmq客戶端。APN01上的Rabbitmq客戶端收到消息後進行處理，再調用APNO1與IME01的連接，將消息發送給設備IME01。
發送集羣非本節點消息流程圖：
附：Androidpn是韓國Sehwan No寫的開源消息推送項目，很多大公司都用這個消息推送方式構建自己的消息推送服務，缺點是導致客戶端比較耗電。通信機制分別由客戶端和服務器完成。