摘要：最近對(duì)服務(wù)器推送技術(shù)比較感興趣，在網(wǎng)上也看了好些文章，由于每個(gè)人理解的不同，實(shí)現(xiàn)細(xì)節(jié)或者語言表達(dá)方式不同，本人被各種名詞或者技術(shù)實(shí)現(xiàn)搞的頭大，于是自己準(zhǔn)備整理下。定時(shí)器就可以實(shí)現(xiàn)，每次請(qǐng)求如果服務(wù)器端有更新數(shù)據(jù)則響應(yīng)到客戶端。

最近對(duì)服務(wù)器推送技術(shù)比較感興趣，在網(wǎng)上也看了好些文章，由于每個(gè)人理解的不同，實(shí)現(xiàn)細(xì)節(jié)或者語言表達(dá)方式不同，本人被各種名詞或者技術(shù)實(shí)現(xiàn)搞的頭大，于是自己準(zhǔn)備整理下。

首先實(shí)現(xiàn)服務(wù)器推送技術(shù)一直一來是B/S應(yīng)用開發(fā)的一塊難題，因?yàn)槭腔贖TTP協(xié)議的，HTTP協(xié)議為無狀態(tài)，單向性的協(xié)議，這種情況導(dǎo)致只有客戶端請(qǐng)求，服務(wù)器才能被動(dòng)響應(yīng)結(jié)果，雖然HTTP協(xié)議的優(yōu)勢(shì)是很大的，高效，高伸縮性等。但是有優(yōu)勢(shì)自然有不足，譬如我想做個(gè)聊天室，這種情況導(dǎo)致服務(wù)器無法主動(dòng)向客戶端推送消息，這就有了瓶頸。

....于是人們就開始尋找各種解決方案了。

一種就是控制客戶端的頁面不斷的進(jìn)行ajax請(qǐng)求，應(yīng)該很好實(shí)現(xiàn)吧。js定時(shí)器就可以實(shí)現(xiàn)，每次請(qǐng)求如果服務(wù)器端有更新數(shù)據(jù)則響應(yīng)到客戶端。但是這會(huì)造成服務(wù)器的嚴(yán)重壓力，如果在線用戶數(shù)量過多的話，每隔個(gè)一兩秒請(qǐng)求一次，哪個(gè)服務(wù)器能受得了，這種肯定不太現(xiàn)實(shí)，或者是最無奈的實(shí)現(xiàn)方法。

于是出現(xiàn)了 comet ，comet技術(shù)是服務(wù)器推技術(shù)的一個(gè)總稱，但不是具體實(shí)現(xiàn)方式。下面我將會(huì)講兩種實(shí)現(xiàn)方式，是基于HTTP長(zhǎng)連接的實(shí)現(xiàn)。

第一種叫做長(zhǎng)輪詢（long-polling)方式，它同樣使用的ajax,簡(jiǎn)單說一下，就是客戶端使用ajax發(fā)送一個(gè)請(qǐng)求，服務(wù)器端肯定會(huì)開啟一個(gè)線程，這個(gè)線程會(huì)時(shí)時(shí)監(jiān)測(cè)要請(qǐng)求的數(shù)據(jù)是否有變化，如果有變化，則向客戶端輸出最新消息，并關(guān)閉鏈接，客戶端收到消息處理之后，再次向服務(wù)器端請(qǐng)求，如此循環(huán)，所以叫長(zhǎng)輪詢，這種實(shí)現(xiàn)方式比起上一種自然要好的多了，不需要客戶端不斷的ajax請(qǐng)求，減輕服務(wù)器端的一定壓力，而且可以算得上是實(shí)時(shí)的。

另外一種是流方式，這種和長(zhǎng)輪詢方式挺像，只有一點(diǎn)區(qū)別，就是流方式是在客戶端請(qǐng)求服務(wù)端并建立鏈接之后，服務(wù)器端始終不會(huì)關(guān)閉鏈接（直到超時(shí)，斷電或者其他特殊情況）每次有數(shù)據(jù)時(shí)，就向客戶端進(jìn)行輸出，而不像長(zhǎng)輪詢每次向客戶端輸出之后，都要關(guān)閉鏈接。

關(guān)于長(zhǎng)輪詢和流方式注意以下：

在長(zhǎng)輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 為 4（即數(shù)據(jù)傳輸結(jié)束）時(shí)調(diào)用回調(diào)函數(shù)，進(jìn)行信息處理。當(dāng) readystate 為 4 時(shí)，數(shù)據(jù)傳輸結(jié)束，連接已經(jīng)關(guān)閉，長(zhǎng)輪詢方式IE、Mozilla FireFox 都支持。而至于流方式，Mozilla Firefox 提供了對(duì)流方式的支持，即 readystate 為 3 時(shí)（數(shù)據(jù)仍在傳輸中），客戶端可以讀取數(shù)據(jù)，從而無須關(guān)閉連接，就能讀取處理服務(wù)器端返回的信息。IE 在 readystate 為 3 時(shí)，不能讀取服務(wù)器返回的數(shù)據(jù)，目前 IE 不支持流方式。

comet實(shí)現(xiàn)瓶頸解決——服務(wù)器servlet線程阻塞問題

到這里大家可能會(huì)想到另外一個(gè)問題，那就是客戶端每來一個(gè)請(qǐng)求，都要在服務(wù)器端開一個(gè)線程來監(jiān)測(cè)數(shù)據(jù)是否發(fā)生變化，即使數(shù)據(jù)很長(zhǎng)時(shí)間內(nèi)都不會(huì)發(fā)生改變，這條線程依然
在這里阻塞著，資源不能得到釋放，線程在這里又沒其他事干，如果有過多的用戶、過多的線程，自然會(huì)造成服務(wù)器的資源，內(nèi)存不足的情況。這是個(gè)問題，不過既然有問題，自然有解決方法。
目前有兩種解決方法，第一種是利用Tomcat 和 Jetty這兩種開源服務(wù)器對(duì)NIO的支持 代碼實(shí)現(xiàn)和添加服務(wù)器支持可以參考http://www.ibm.com/developerw...，第二種則是Java 1.6 出來的Servlet3.0，Servlet3.0可以實(shí)現(xiàn)真正的異步處理，就是新開一個(gè)線程用于處理復(fù)雜業(yè)務(wù)，而servlet線程本身則繼續(xù)往下執(zhí)行直到結(jié)束之后，再返回servlet容器，待到另一條線程業(yè)務(wù)處理完之后，再向客戶端輸出結(jié)果。但是使用servlet3.0，需要tomcat7和以上才支持，servlet3.0的實(shí)現(xiàn)百度就有好多，就不在此多贅述了。只談理論。。。

參考：http://www.ibm.com/developerw...
https://software.intel.com/zh...
http://www.itjhwd.com/comet-j...

https://www.cnblogs.com/wodem...【有案例】