最近公司的幾個項目都有消息推送的需求，所以五一期間一直在探索這方面的相關技術。

一、消息推送方案（輪詢、長連接）

輪詢：比較簡單的，最容易理解和實現(xiàn)的就是客戶端去服務器上拉信息，信息的及時性要求越高則拉信息的頻率越高?？蛻舳死畔⒌挠|發(fā)可以是一些事件，也可以是一個定時器，不斷地去查詢服務器。所以這個方案的弊端也是顯而易見的，在輪詢的頻率較高時，服務器端的壓力很大，通訊的流量也很大，并且大部分時間都是做的無用功。

長連接：客戶端和服務端維持一個長連接，服務端在有信息推送的時候，借助這個連接把信息發(fā)送到客戶端。這個方案的優(yōu)點是信息推送的及時性很高，基本是實時的，并且除了維持連接的心跳，不會產(chǎn)生額外的流量，但服務端需要維持連接，當客戶端數(shù)量龐大的時候，服務器的資源消耗也會很大。本文后面提到的幾個框架，都借助Java的NIO特性，緩解了服務端的壓力和資源消耗，但畢竟是有連接，在性能上還是無法跟傳統(tǒng)的HTTP無連接服務端比較。

其他：在手機端，其實還可以有短信、郵件等方式，來進行信息推送。這些方式由于牽涉到運營商和手機操作系統(tǒng)的內置服務框架，限制較多，何況微信都要被收費，所以就不去考慮了。

二、開源框架（Androidpn、Openfire、MINA、Netty）

Android手機應用，信息推送的資料大多都是關于androidpn的，這是一個基于XMPP協(xié)議的Java開源信息推送方案，包括完整的服務端和客戶端。服務端有Tomcat和Jetty兩個版本，下載下來后配置一下數(shù)據(jù)庫連接參數(shù)和IP端口就可以跑起來了。客戶端則可以參考它的示例，把Android代碼拿過來用即可。所以這是一個針對android應用的高度定制版，如果要對服務端進行修改調整，動的地方比較多。

Openfire則適用的范圍更廣，是基于XMPP協(xié)議的開源實時協(xié)作服務器，可以通過它簡單地搭建一個IM平臺。Androidpn是在Openfire上做了簡化，只針對Android的消息推送。從這里也可看出，就消息推送來說，用XMPP協(xié)議有點殺雞用牛刀了。

MINA和Netty是Socket框架，是同一個作者的，架構差別不大。MINA歸Apache管，Openfire和Androidpn都是用的MINA；Netty則歸JBOSS管，從我檢索到的資料來看，更多偏向于Netty，大致是認為Netty的性能稍優(yōu)，文檔與例子更完整。

三、消息推送服務（GCM/C2DM、百度云推送）

其實也有一些現(xiàn)存的云推送服務可供選擇，并不一定要自己來搭建一個平臺。谷歌的GCM，Google Cloud Messaging，是C2DM的升級版，Android終端用的話，本來是最合適不過了，但在國內大家都懂的，玩的是《墻來了》游戲，有時你可以鉆過去，有時會被撞落水，所以不靠譜啊。百度和其他的一些公司，也提供云推送服務，好像沒有免費的。谷歌應該比較郁悶吧，Android上的搜索、地圖、郵件、推送等等，在國內都是為他人作嫁衣裳。

四、回歸本質-協(xié)議（TCP/IP、HTTP、XMPP、MQTT）

沒想到一個消息推送可以有這么多“內涵”啊。本質上，不就是維持一個連接，服務端需要推送消息的時候就通過這些連接往客戶端傳信息嘛。仔細想來，要想靈活和可控，最好的方式還是自己基于TCP/IP協(xié)議來實現(xiàn)消息推送。再往上一點，就是在HTTP協(xié)議上來實現(xiàn)，這樣的話既可以穿越防火墻，也可以通過AJAX實現(xiàn)網(wǎng)頁上的消息推送。Servlet 3.0的異步請求支持，其實也是可以用來做消息推送的。XMPP和MQTT協(xié)議要復雜些，最好選一個開源框架來搭建。