Java 服務端推送消息有那麼難嗎？

今天項目經理交給我一個開發任務。若是有人在前臺下了訂單就給後臺倉庫管理一個髮貨通知。也就是服務端觸發一個事件，推送消息到客戶端。

若是我用websocket來作還要搞個websocket服務器，並且還 有很多配置。websocket是全雙工通訊，單向通訊簡直是殺雞用牛刀。用輪詢吧，浪費服務器資源不說，還不必定實時，訂單處理慢了豈不是怠慢了客戶。有沒有別的選擇呢？固然有！

1. SSE推送技術

SSE全稱Server-sent Events，是HTML 5 規範的一個組成部分，具體去MDN網站查看相關文檔。該規範十分簡單，主要由兩個部分組成：第一個部分是服務器端與瀏覽器端之間的通信協議，第二部分是在瀏覽器端可供 JavaScript 使用的 EventSource 對象。通信協議是基於純文本的簡單協議。服務器響應的內容類型是「text/event-stream」。響應文本的內容能夠當作是一個事件流，由不一樣的事件所組成。每一個事件由類型和數據兩部分組成，同時每一個事件能夠有一個可選的標識符。不一樣事件的內容之間經過僅包含回車符和換行符的空行（「\r\n」）來分隔。每一個事件的數據可能由多行組成。

如上圖所示，每一個事件之間經過空行來分隔。每一行都是由鍵值對組成。若是鍵爲空則表示該行爲註釋，會在處理時被忽略。例如第10行。

第1行表示一個只包含數據的事件。會按照默認事件走（message事件）。第3-4行表明一個附帶eventID的事件。第6-8行表明一個自定義事件。第10-14行表明一個多行數據事件，多行數據由換行符連接

key定義有如下幾種：

• data，表示該行包含的是數據。以 data 開頭的行能夠出現屢次。全部這些行都是該事件的數據。

• event，表示該行用來聲明事件的類型。瀏覽器在收到數據時，會產生對應類型的事件。默認提供三個標準事件（固然你能夠自定義）：

• id，表示該行用來聲明事件的標識符。服務器端返回的數據中包含了事件的標識符，瀏覽器會記錄最近一次接收到的事件的標識符。若是與服務器端的鏈接中斷，當瀏覽器端再次進行鏈接時，會經過 HTTP 頭「Last-Event-ID」來聲明最後一次接收到的事件的標識符。服務器端能夠經過瀏覽器端發送的事件標識符來肯定從哪一個事件開始來繼續鏈接。

• retry，表示該行用來聲明瀏覽器在鏈接斷開以後進行再次鏈接以前的等待時間。

SSE只適用於高級瀏覽器，可是注意IE不直接支持。IE上的XMLHttpRequest對象不支持獲取部分的響應內容，因此不支持。每次總有IE，怪不得快被淘汰了。

2. SSE VS Websocket

• SSE 只能Server到Client單項，而Websocket是雙向通訊。

• SSE 比 Websocket 輕量。固然功能要簡單的多。開發便利，不牽涉協議升級問題。

• SSE 自然支持斷線重連

3. Spring Mvc中的SSE

Spring Mvc對SSE進行了支持。若是你要聲明一個SSE鏈接。只須要在你的控制器聲明一個以下接口：

必須必須返回SseEmitter對象，SseEmitter對象是Session級別的，若是你要點對點針對每一個session要獨立存儲。若是你是廣播能夠共用一個SseEmitter對象。按照SSE規範也必須聲明produces爲"text/event-stream"。當你調用該接口的時候將創建起SSE鏈接。

你能夠在另外一個線程中調用SseEmitter的send方法向客戶端發送事件。你也能夠在發送事件後調用complete方法來關閉SSE鏈接。

4. 瀏覽器端的EventSource

因爲SSE 是HTML5規範。因此對於APP端必須有HTML才能支持。而且IE若是要支持須要使用一些兼容開發包，好比polyfill庫。客戶端由於只接受事件因此開發比較簡單：

• 聲明客戶端鏈接， 初始化EventSource對象。

• 編寫監聽器來監聽事件。

總結

今天介紹了SSE 服務端推送。和長輪訓、comet、websocket相比而言比較輕量級。在一些須要服務器實時推送規模不大的業務場景實現更簡單點。相信看了本文後你會很快入門。在實際開發中要根據業務對這幾種推送進行技術選型。沒有最好的只有最適合的。SSE對大多數開發者來講不夠熟悉。

關注公衆號領資料
搜索公衆號【Java耕耘者】,回覆【Java】，便可獲取大量優質電子書和一份Java高級架構資料、Spring源碼分析、Dubbo、Redis、Netty、zookeeper、Spring cloud、分佈式等視頻資料