在開發的項目中，需要實時獲取最新的股價，實時顯示項目在線人數，即時通訊等。你會通過什麼方法實現呢？下面就說說實時獲取數據的幾種方式，我儘量按照從low到複雜的順序羅列。
http協議
HTTP協議大家都很熟悉了，開始本文之前，首先簡單回顧一下HTTP協議。
HTTP協議是建立在TCP協議上的應用層協議，協議的本質是請求----應答：
即對於HTTP協議來說，服務端給一次響應後整個請求就結束了，這是HTTP請求最大的特點，也是由於這個特點，HTTP請求無法做到的是服務端向客戶端主動推送數據。
但由於HTTP協議的廣泛應用，很多時候確實又想使用HTTP協議去實現實時的數據獲取，這種時候應當怎麼辦呢？下面首先介紹幾種基於HTTP協議的實時數據獲取方法。
ifram/frame
對於菜鳥來說，這未必不是個聰明的解決方法。在需要顯示的區域嵌入一個frame框，然後通過js或meta標籤控制，不停的刷新獲取。
優點：簡單實用。
缺點：不停地向服務器請求，對服務器壓力最大。
應用場景：局域網，客戶端數量不大
短輪詢
這裏我們要用到ajax了，還是通過Js重複的請求服務器來獲取實時數據。比起frame刷新，減少了瀏覽器的渲染過程。並且因爲使用了異步處理，沒有畫面閃現。交互效果更好。
優點：異步處理，交互效果好
缺點：仍然需要不停地向服務器請求
應用場景：短時間的獲取數據，比如支付狀態，授權登錄狀態判斷等
客戶端向服務端請求數據，服務端立即將數據返回給客戶端，客戶端沒有拿到想要的數據（比如返回結果告訴客戶端，數據處理中），客戶端繼續發請求，服務端繼續立即響應，週而復始。
這種實時數據獲取的方式比較粗暴，優點在於編程簡單，客戶端發請求，服務端實時迴響應即可。缺點主要有兩個：
- 無效請求多，每一次無效請求都在浪費帶寬和服務器的計算資源
- 對服務器壓力大，定時發請求，併發一高，可能服務端瞬間會收到成千上萬個請求，很容易拖垮服務器甚至導致宕機
那麼短輪詢適合哪種使用場景呢，按照我的理解如果數據變化比較頻繁或者能預期到數據在短時間內會發生一次變化的場景可以使用短輪詢，比如：
用戶在PC端買了一個東西喚起網頁端，由於PC端和網頁端是不通的，我們預期到用戶應該很快會完成付款，這種時候爲了開發簡單短輪詢是一種可以使用的方式，直接服務端提供一個接口告訴客戶端訂單狀態，客戶端每5秒請求一次即可，拿到結果就可以不用請求了。
使用短輪詢注意要做好請求次數上限的控制，比如請求100次還沒檢測到用戶付款，可以彈窗"請完成付款後去我的訂單頁面查詢"就可以不用請求了。
長輪詢
長輪詢與短輪詢的唯一區別是，服務端會判斷數據變化來響應客戶端。如果數據未發生變化，則暫時阻塞。這樣就減少了許多無意義的重複請求
優點：減少請求響應次數
缺點：仍然需要不停地向服務器請求，還有掛起時比較消耗內存。
應用場景：icommet等插件就是用的長輪詢。
本質上沒有改變，依然是客戶端在沒有收到自己想要數據的情況下不斷髮送請求給服務端，差別在於服務端收到請求不再直接給響應，而是將請求掛起，自己去定時判斷數據的變化，有變化就立馬返回給客戶端，沒有就等到超時爲止。
可以很明顯的看到，長輪詢的優點就是客戶端的請求少了很多避免了無謂的客戶端請求，缺點則是服務端會掛起大量請求增加資源消耗且服務器對HTTP請求併發數量是有限制的。
微信網頁版的登陸是一個典型的長輪詢的例子：
從圖上看，客戶端不斷髮送請求到服務器，服務器第一時間並沒有給出迴應，於是客戶端等待，在超時的情況下繼續發送請求。
總的來說我理解一般使用長輪詢會更多一點，短輪詢更加看重的是編程簡單，適合小型應用。像微信網頁端登錄這種，成千上萬個用戶同時登陸，隔一段時間服務端收成千上個請求去處理哪裏受得了，堆機器分攤每臺服務器上處理請求的數量終究不是解決問題的辦法。
websocket協議
上面介紹了兩種輪詢方式，但是兩種綜合起來都有比較明顯的缺點，總結起來有以下幾個：
- 僞實時，即上述兩種方式都不是真正的實時，無論短輪詢的客戶端輪詢時間多短，還是長輪詢的服務端輪詢時間多短，都存在一定程度的延時
- 所有的輪詢只要沒有需要的數據返回，都是對計算資源的一種浪費
- HTTP協議本身是一個重的協議，每一次都必須帶有HTTP首部+HTTP頭部，實際上對我們來說需要的只是HTTP Body而已，多餘的數據都是對帶寬的一種浪費
因此，最好我們可以做到的事情是：客戶端和服務端之間有一條通路，當服務端數據有變化的時候，服務端可以主動推送到客戶端。WebSocket就是HTML5之後爲了做到這一點而誕生的一種協議，雖然這是一種新的協議，但也是基於HTTP協議的。
與http協議很相似也需要三次握手，只是服務器返回的狀態碼不是200，而是101.意味着接下來客戶端與服務端之間的通信是通過websocket來進行的。這個通信服務端會阻塞，是不會中斷的。每當有數據變化時就會主動傳給客戶端。
看一下WebSocket的原理，很簡單：
WebSocket客戶端首先通過HTTP協議發送幾個特別的header到服務端，告訴服務端現在我發起的是HTTP請求，但我要升級到WebSocket了：
- Upgrade:websocket
- Connection：Upgrade
- Sec-WebSocket-Key: XXX
- Sec-WebSocket-Protocol: chat, superchat
- Sec-WebSocket-Version: XX
只要服務器支持WebSocket協議（Tomcat7、Jetty7之後都是支持WebSocket的），那麼服務端收到請求且建立連接成功後會返回Sec-WebSocket-Accept、Sec-WebSocket-Protocol這兩個header給客戶端，且Http Status爲101表示協議切換成功，這樣客戶端和服務端只要任意一方沒有斷開連接，就可以基於這一條通路進行通訊了。
再談一下之前提的WebSocket相比長短輪詢對於帶寬資源的節省。有一個測試，假設HTTP Header是871字節，WebSocket由於數據傳輸是基於幀的，幀傳輸更加高效，對比長短輪詢，2個字節即可代替871個字節的Header，測試結果爲：
相同的每秒客戶端輪詢的次數，當次數高達10W/s的高頻率次數的時候，輪詢需要消耗665Mbps，而WebSocket僅僅只花費了1.526Mbps，將近435倍。
WebSocket做到了真正的實時且大量節省帶寬資源，但是我理解也有自己的問題，就是開發成本比較高，這裏的開發成本倒不是說自己去實現WebSocket，這個在Java語言層面上直接使用Netty-Socketio即可，API很簡單，提供了對WebSocket完整的實現，真正的開發成本在於分佈式環境下的數據同步問題。
舉個例子，有一個在線聊天系統10W人同時在線，此時有一個用戶發了一條1K的語音消息，單機保持10W的連接倒是可以（這裏不是HTTP請求，因此不受連接池數影響），問題在於帶寬。單機同時向10W用戶推送1K語音消息，需要的帶寬至少10M，這還只是純粹推送數據出去，沒有考慮到數據進來的場景，實際運行過程中需要的帶寬會更多，對於企業來說這是一筆非常大的成本。
因此，大量連接的場景下都會做集羣（實際就算沒有大量連接，爲了高可用性，也會做集羣），10W併發分出5臺機器，平均每臺機器有2W連接，考慮集羣下會出現的問題：
客戶端1把數據發送到服務器1，服務器1連接的所有客戶端都可以推送該條語音，但是問題在於：
- 服務器2~服務器5連的所有客戶端如何拿到數據？簡單的一種方式是使用消息隊列，將數據通過消息隊列發送到所有訂閱的服務器上
- 那如果傳輸的是一張1M的圖片，數據太大不適合使用消息隊列怎麼辦，可以先將數據存儲下來，消息隊列只發送id，收到消息的服務器再根據id去取真正的數據並推送
- 如果依賴消息隊列，那麼不僅僅需要對應用進行代碼開發，還需要對消息服務器做分佈式集羣、做壓力測試，保證高可用
- 2W連接正常預計發送1K的消息是沒問題的，但是萬一用戶發送了1M圖片導致遠超預估帶寬怎麼辦，是業務上取捨不能發送超過XXX的數據還是技術上處理
其他太多需要考慮的問題沒有列出來，總而言之，用WebSocket在大量請求、高併發的場景下，代碼開發成本是非常高的。但是由於WebSocket可以做到真正的實時服務端對客戶端的數據推送且對帶寬資源有大量的節省，因此很多IM、音視頻、彈幕等應用都會使用WebSocket。
websocket
比起http協議，websocket節不需要重複請求。而且響應數據不必包含header頭文件，只響應body部分。因此節省了流量和服務器壓力。實現了真正的實時數據。
優點：不用重複請求服務器，響應數據不用帶header頭
缺點：不兼容低版本IE,開發相對複雜。
應用場景：對數據實時變化要求高的場景
xmpp
xmpp是在websocket基礎上的即時通信協議，主要應用於即時通訊。數據傳輸使用xmL格式。
優點：有相應的框架,sdk，使用簡單。
缺點：請求過多時，對服務器內存，cpu要求較高
應用場景：即時通訊
結語
本文說了實時獲取數據的幾種方式，針對不同的應用場景和實際情況採納不同的方案，有時候簡單一點挺好。