最近公司的幾個項目都有消息推送的需求，所以五一期間一直在探索這方面的相關技術。
一、消息推送方案（輪詢、長連接）
輪詢：比較簡單的，最容易理解和實現的就是客戶端去服務器上拉信息，信息的及時性要求越高則拉信息的頻率越高。客戶端拉信息的觸發可以是一些事件，也可以是一個定時器，不斷地去查詢服務器。所以這個方案的弊端也是顯而易見的，在輪詢的頻率較高時，服務器端的壓力很大，通訊的流量也很大，並且大部分時間都是做的無用功。長連接：客戶端和服務端維持一個長連接，服務端在有信息推送的時候，藉助這個連接把信息發送到客戶端。這個方案的優點是信息推送的及時性很高，基本是實時的，並且除了維持連接的心跳，不會產生額外的流量，但服務端需要維持連接，當客戶端數量龐大的時候，服務器的資源消耗也會很大。本文後面提到的幾個框架，都藉助Java的NIO特性，緩解了服務端的壓力和資源消耗，但畢竟是有連接，在性能上還是無法跟傳統的HTTP無連接服務端比較。其他：在手機端，其實還可以有短信、郵件等方式，來進行信息推送。這些方式由於牽涉到運營商和手機操作系統的內置服務框架，限制較多，何況微信都要被收費，所以就不去考慮了。
二、開源框架（Androidpn、Openfire、MINA、Netty）
Android手機應用，信息推送的資料大多都是關於androidpn的，這是一個基於XMPP協議的Java開源信息推送方案，包括完整的服務端和客戶端。服務端有Tomcat和Jetty兩個版本，下載下來後配置一下數據庫連接參數和IP端口就可以跑起來了。客戶端則可以參考它的示例，把Android代碼拿過來用即可。所以這是一個針對android應用的高度定製版，如果要對服務端進行修改調整，動的地方比較多。Openfire則適用的範圍更廣，是基於XMPP協議的開源實時協作服務器，可以通過它簡單地搭建一個IM平臺。Androidpn是在Openfire上做了簡化，只針對Android的消息推送。從這裏也可看出，就消息推送來說，用XMPP協議有點殺雞用牛刀了。MINA和Netty是Socket框架，是同一個作者的，架構差別不大。MINA歸Apache管，Openfire和Androidpn都是用的MINA；Netty則歸JBOSS管，從我檢索到的資料來看，更多偏向於Netty，大致是認爲Netty的性能稍優，文檔與例子更完整。
三、消息推送服務（GCM/C2DM、百度雲推送）
其實也有一些現存的雲推送服務可供選擇，並不一定要自己來搭建一個平臺。谷歌的GCM，Google Cloud Messaging，是C2DM的升級版，Android終端用的話，本來是最合適不過了，但在國內大家都懂的，玩的是《牆來了》遊戲，有時你可以鑽過去，有時會被撞落水，所以不靠譜啊。百度和其他的一些公司，也提供雲推送服務，好像沒有免費的。谷歌應該比較鬱悶吧，Android上的搜索、地圖、郵件、推送等等，在國內都是爲他人作嫁衣裳。
四、迴歸本質-協議（TCP/IP、HTTP、XMPP、MQTT）
沒想到一個消息推送可以有這麼多“內涵”啊。本質上，不就是維持一個連接，服務端需要推送消息的時候就通過這些連接往客戶端傳信息嘛。仔細想來，要想靈活和可控，最好的方式還是自己基於TCP/IP協議來實現消息推送。再往上一點，就是在HTTP協議上來實現，這樣的話既可以穿越防火牆，也可以通過AJAX實現網頁上的消息推送。Servlet 3.0的異步請求支持，其實也是可以用來做消息推送的。XMPP和MQTT協議要複雜些，最好選一個開源框架來搭建。