java實現web實時消息推送的七種方案

引言

做瞭一個小破站,現在要實現一個站內信web消息推送的功能,對,就是下圖這個小紅點,一個很常用的功能。

不過他還沒想好用什麼方式做,這裡我幫他整理瞭一下幾種方案,並簡單做瞭實現。

案例下載

什麼是消息推送(push)

推送的場景比較多,比如有人關註我的公眾號,這時我就會收到一條推送消息,以此來吸引我點擊打開應用。

消息推送(push)通常是指網站的運營工作等人員,通過某種工具對用戶當前網頁或移動設備APP進行的主動消息推送。

消息推送一般又分為web端消息推送移動端消息推送

上邊的這種屬於移動端消息推送,web端消息推送常見的諸如站內信、未讀郵件數量、監控報警數量等,應用的也非常廣泛。

在具體實現之前,咱們再來分析一下前邊的需求,其實功能很簡單,隻要觸發某個事件(主動分享瞭資源或者後臺主動推送消息),web頁面的通知小紅點就會實時的+1就可以瞭。

通常在服務端會有若幹張消息推送表,用來記錄用戶觸發不同事件所推送不同類型的消息,前端主動查詢(拉)或者被動接收(推)用戶所有未讀的消息數。

消息推送無非是推(push)和拉(pull)兩種形式,下邊我們逐個瞭解下。

短輪詢

輪詢(polling)應該是實現消息推送方案中最簡單的一種,這裡我們暫且將輪詢分為短輪詢長輪詢

短輪詢很好理解,指定的時間間隔,由瀏覽器向服務器發出HTTP請求,服務器實時返回未讀消息數據給客戶端,瀏覽器再做渲染顯示。

一個簡單的JS定時器就可以搞定,每秒鐘請求一次未讀消息數接口,返回的數據展示即可。

setInterval(() => {
  // 方法請求
  messageCount().then((res) => {
      if (res.code === 200) {
          this.messageCount = res.data
      }
  })
}, 1000);

效果還是可以的,短輪詢實現固然簡單,缺點也是顯而易見,由於推送數據並不會頻繁變更,無論後端此時是否有新的消息產生,客戶端都會進行請求,勢必會對服務端造成很大壓力,浪費帶寬和服務器資源。

長輪詢

長輪詢是對上邊短輪詢的一種改進版本,在盡可能減少對服務器資源浪費的同時,保證消息的相對實時性。長輪詢在中間件中應用的很廣泛,比如Nacosapollo配置中心,消息隊列kafkaRocketMQ中都有用到長輪詢。

Nacos配置中心交互模型是push還是pull?一文中我詳細介紹過Nacos長輪詢的實現原理,感興趣的小夥伴可以瞅瞅。

這次我使用apollo配置中心實現長輪詢的方式,應用瞭一個類

DeferredResult可以允許容器線程快速釋放占用的資源,不阻塞請求線程,以此接受更多的請求提升系統的吞吐量,然後啟動異步工作線程處理真正的業務邏輯,處理完成調用DeferredResult.setResult(200)提交響應結果。

下邊我們用長輪詢來實現消息推送。

因為一個ID可能會被多個長輪詢請求監聽,所以我采用瞭guava包提供的Multimap結構存放長輪詢,一個key可以對應多個value。一旦監聽到key發生變化,對應的所有長輪詢都會響應。前端得到非請求超時的狀態碼,知曉數據變更,主動查詢未讀消息數接口,更新頁面數據。

@Controller
@RequestMapping("/polling")
public class PollingController {
    // 存放監聽某個Id的長輪詢集合
    // 線程同步結構
    public static Multimap<String, DeferredResult<String>> watchRequests = Multimaps.synchronizedMultimap(HashMultimap.create());
    /**
     * 公眾號:程序員小富
     * 設置監聽
     */
    @GetMapping(path = "watch/{id}")
    @ResponseBody
    public DeferredResult<String> watch(@PathVariable String id) {
        // 延遲對象設置超時時間
        DeferredResult<String> deferredResult = new DeferredResult<>(TIME_OUT);
        // 異步請求完成時移除 key,防止內存溢出
        deferredResult.onCompletion(() -> {
            watchRequests.remove(id, deferredResult);
        });
        // 註冊長輪詢請求
        watchRequests.put(id, deferredResult);
        return deferredResult;
    }
    /**
     * 公眾號:程序員小富
     * 變更數據
     */
    @GetMapping(path = "publish/{id}")
    @ResponseBody
    public String publish(@PathVariable String id) {
        // 數據變更 取出監聽ID的所有長輪詢請求,並一一響應處理
        if (watchRequests.containsKey(id)) {
            Collection<DeferredResult<String>> deferredResults = watchRequests.get(id);
            for (DeferredResult<String> deferredResult : deferredResults) {
                deferredResult.setResult("我更新瞭" + new Date());
            }
        }
        return "success";
    }

當請求超過設置的超時時間,會拋出AsyncRequestTimeoutException異常,這裡直接用@ControllerAdvice全局捕獲統一返回即可,前端獲取約定好的狀態碼後再次發起長輪詢請求,如此往復調用。

@ControllerAdvice
public class AsyncRequestTimeoutHandler {
    @ResponseStatus(HttpStatus.NOT_MODIFIED)
    @ResponseBody
    @ExceptionHandler(AsyncRequestTimeoutException.class)
    public String asyncRequestTimeoutHandler(AsyncRequestTimeoutException e) {
        System.out.println("異步請求超時");
        return "304";
    }
}

我們來測試一下,首先頁面發起長輪詢請求/polling/watch/10086監聽消息更變,請求被掛起,不變更數據直至超時,再次發起瞭長輪詢請求;緊接著手動變更數據/polling/publish/10086,長輪詢得到響應,前端處理業務邏輯完成後再次發起請求,如此循環往復。

長輪詢相比於短輪詢在性能上提升瞭很多,但依然會產生較多的請求,這是它的一點不完美的地方。

iframe流

iframe流就是在頁面中插入一個隱藏的<iframe>標簽,通過在src中請求消息數量API接口,由此在服務端和客戶端之間創建一條長連接,服務端持續向iframe傳輸數據。

傳輸的數據通常是HTML、或是內嵌的javascript腳本,來達到實時更新頁面的效果。

這種方式實現簡單,前端隻要一個<iframe>標簽搞定瞭

<iframe src="/iframe/message" style="display:none"></iframe>

服務端直接組裝html、js腳本數據向response寫入就行瞭

@Controller
@RequestMapping("/iframe")
public class IframeController {
    @GetMapping(path = "message")
    public void message(HttpServletResponse response) throws IOException, InterruptedException {
        while (true) {
            response.setHeader("Pragma", "no-cache");
            response.setDateHeader("Expires", 0);
            response.setHeader("Cache-Control", "no-cache,no-store");
            response.setStatus(HttpServletResponse.SC_OK);
            response.getWriter().print(" <script type=\"text/javascript\">\n" +
                    "parent.document.getElementById('clock').innerHTML = \"" + count.get() + "\";" +
                    "parent.document.getElementById('count').innerHTML = \"" + count.get() + "\";" +
                    "</script>");
        }
    }
}

但我個人不推薦,因為它在瀏覽器上會顯示請求未加載完,圖標會不停旋轉,簡直是強迫癥殺手。

SSE (我的方式)

很多人可能不知道,服務端向客戶端推送消息,其實除瞭可以用WebSocket這種耳熟能詳的機制外,還有一種服務器發送事件(Server-sent events),簡稱SSE

SSE它是基於HTTP協議的,我們知道一般意義上的HTTP協議是無法做到服務端主動向客戶端推送消息的,但SSE是個例外,它變換瞭一種思路。

SSE在服務器和客戶端之間打開一個單向通道,服務端響應的不再是一次性的數據包而是text/event-stream類型的數據流信息,在有數據變更時從服務器流式傳輸到客戶端。

整體的實現思路有點類似於在線視頻播放,視頻流會連續不斷的推送到瀏覽器,你也可以理解成,客戶端在完成一次用時很長(網絡不暢)的下載。

SSEWebSocket作用相似,都可以建立服務端與瀏覽器之間的通信,實現服務端向客戶端推送消息,但還是有些許不同:

  • SSE 是基於HTTP協議的,它們不需要特殊的協議或服務器實現即可工作;WebSocket需單獨服務器來處理協議。
  • SSE 單向通信,隻能由服務端向客戶端單向通信;webSocket全雙工通信,即通信的雙方可以同時發送和接受信息。
  • SSE 實現簡單開發成本低,無需引入其他組件;WebSocket傳輸數據需做二次解析,開發門檻高一些。
  • SSE 默認支持斷線重連;WebSocket則需要自己實現。
  • SSE 隻能傳送文本消息,二進制數據需要經過編碼後傳送;WebSocket默認支持傳送二進制數據。

SSE 與 WebSocket 該如何選擇?

技術並沒有好壞之分,隻有哪個更合適

SSE好像一直不被大傢所熟知,一部分原因是出現瞭WebSockets,這個提供瞭更豐富的協議來執行雙向、全雙工通信。對於遊戲、即時通信以及需要雙向近乎實時更新的場景,擁有雙向通道更具吸引力。

但是,在某些情況下,不需要從客戶端發送數據。而你隻需要一些服務器操作的更新。比如:站內信、未讀消息數、狀態更新、股票行情、監控數量等場景,SEE不管是從實現的難易和成本上都更加有優勢。此外,SSE 具有WebSockets在設計上缺乏的多種功能,例如:自動重新連接事件ID發送任意事件的能力。

前端隻需進行一次HTTP請求,帶上唯一ID,打開事件流,監聽服務端推送的事件就可以瞭

<script>
    let source = null;
    let userId = 7777
    if (window.EventSource) {
        // 建立連接
        source = new EventSource('http://localhost:7777/sse/sub/'+userId);
        setMessageInnerHTML("連接用戶=" + userId);
        /**
         * 連接一旦建立,就會觸發open事件
         * 另一種寫法:source.onopen = function (event) {}
         */
        source.addEventListener('open', function (e) {
            setMessageInnerHTML("建立連接。。。");
        }, false);
        /**
         * 客戶端收到服務器發來的數據
         * 另一種寫法:source.onmessage = function (event) {}
         */
        source.addEventListener('message', function (e) {
            setMessageInnerHTML(e.data);
        });
    } else {
        setMessageInnerHTML("你的瀏覽器不支持SSE");
    }
</script>

服務端的實現更簡單,創建一個SseEmitter對象放入sseEmitterMap進行管理

private static Map<String, SseEmitter> sseEmitterMap = new ConcurrentHashMap<>();
/**
 * 創建連接
 *
 * @date: 2022/7/12 14:51
 * @auther: 公眾號:程序員小富
 */
public static SseEmitter connect(String userId) {
    try {
        // 設置超時時間,0表示不過期。默認30秒
        SseEmitter sseEmitter = new SseEmitter(0L);
        // 註冊回調
        sseEmitter.onCompletion(completionCallBack(userId));
        sseEmitter.onError(errorCallBack(userId));
        sseEmitter.onTimeout(timeoutCallBack(userId));
        sseEmitterMap.put(userId, sseEmitter);
        count.getAndIncrement();
        return sseEmitter;
    } catch (Exception e) {
        log.info("創建新的sse連接異常,當前用戶:{}", userId);
    }
    return null;
}
/**
 * 給指定用戶發送消息
 *
 * @date: 2022/7/12 14:51
 * @auther: 公眾號:程序員小富
 */
public static void sendMessage(String userId, String message) {
    if (sseEmitterMap.containsKey(userId)) {
        try {
            sseEmitterMap.get(userId).send(message);
        } catch (IOException e) {
            log.error("用戶[{}]推送異常:{}", userId, e.getMessage());
            removeUser(userId);
        }
    }
}

我們模擬服務端推送消息,看下客戶端收到瞭消息,和我們預期的效果一致。 

註意: SSE不支持IE瀏覽器,對其他主流瀏覽器兼容性做的還不錯。 

MQTT

什麼是 MQTT協議?

MQTT 全稱(Message Queue Telemetry Transport):一種基於發佈/訂閱(publish/subscribe)模式的輕量級通訊協議,通過訂閱相應的主題來獲取消息,是物聯網(Internet of Thing)中的一個標準傳輸協議。

該協議將消息的發佈者(publisher)與訂閱者(subscriber)進行分離,因此可以在不可靠的網絡環境中,為遠程連接的設備提供可靠的消息服務,使用方式與傳統的MQ有點類似。

TCP協議位於傳輸層,MQTT 協議位於應用層,MQTT 協議構建於TCP/IP協議上,也就是說隻要支持TCP/IP協議棧的地方,都可以使用MQTT協議。

為什麼要用 MQTT協議?

MQTT協議為什麼在物聯網(IOT)中如此受偏愛?而不是其它協議,比如我們更為熟悉的 HTTP協議呢?

  • 首先HTTP協議它是一種同步協議,客戶端請求後需要等待服務器的響應。而在物聯網(IOT)環境中,設備會很受制於環境的影響,比如帶寬低、網絡延遲高、網絡通信不穩定等,顯然異步消息協議更為適合IOT應用程序。
  • HTTP是單向的,如果要獲取消息客戶端必須發起連接,而在物聯網(IOT)應用程序中,設備或傳感器往往都是客戶端,這意味著它們無法被動地接收來自網絡的命令。
  • 通常需要將一條命令或者消息,發送到網絡上的所有設備上。HTTP要實現這樣的功能不但很困難,而且成本極高。

具體的MQTT協議介紹和實踐,這裡我就不再贅述瞭,大傢可以參考我之前的兩篇文章,裡邊寫的也都很詳細瞭。

MQTT協議的介紹

我也沒想到 springboot + rabbitmq 做智能傢居,會這麼簡單

MQTT實現消息推送

未讀消息(小紅點),前端 與 RabbitMQ 實時消息推送實踐,賊簡單~

Websocket

websocket應該是大傢都比較熟悉的一種實現消息推送的方式,上邊我們在講SSE的時候也和websocket進行過比較。

WebSocket是一種在TCP連接上進行全雙工通信的協議,建立客戶端和服務器之間的通信渠道。瀏覽器和服務器僅需一次握手,兩者之間就直接可以創建持久性的連接,並進行雙向數據傳輸。

springboot整合websocket,先引入websocket相關的工具包,和SSE相比額外的開發成本。

<!-- 引入websocket -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
</dependency>

服務端使用@ServerEndpoint註解標註當前類為一個websocket服務器,客戶端可以通過ws://localhost:7777/webSocket/10086來連接到WebSocket服務器端。

@Component
@Slf4j
@ServerEndpoint("/websocket/{userId}")
public class WebSocketServer {
    //與某個客戶端的連接會話,需要通過它來給客戶端發送數據
    private Session session;
    private static final CopyOnWriteArraySet<WebSocketServer> webSockets = new CopyOnWriteArraySet<>();
    // 用來存在線連接數
    private static final Map<String, Session> sessionPool = new HashMap<String, Session>();
    /**
     * 公眾號:程序員小富
     * 鏈接成功調用的方法
     */
    @OnOpen
    public void onOpen(Session session, @PathParam(value = "userId") String userId) {
        try {
            this.session = session;
            webSockets.add(this);
            sessionPool.put(userId, session);
            log.info("websocket消息: 有新的連接,總數為:" + webSockets.size());
        } catch (Exception e) {
        }
    }
    /**
     * 公眾號:程序員小富
     * 收到客戶端消息後調用的方法
     */
    @OnMessage
    public void onMessage(String message) {
        log.info("websocket消息: 收到客戶端消息:" + message);
    }
    /**
     * 公眾號:程序員小富
     * 此為單點消息
     */
    public void sendOneMessage(String userId, String message) {
        Session session = sessionPool.get(userId);
        if (session != null && session.isOpen()) {
            try {
                log.info("websocket消: 單點消息:" + message);
                session.getAsyncRemote().sendText(message);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}

前端初始化打開WebSocket連接,並監聽連接狀態,接收服務端數據或向服務端發送數據。

<script>
    var ws = new WebSocket('ws://localhost:7777/webSocket/10086');
    // 獲取連接狀態
    console.log('ws連接狀態:' + ws.readyState);
    //監聽是否連接成功
    ws.onopen = function () {
        console.log('ws連接狀態:' + ws.readyState);
        //連接成功則發送一個數據
        ws.send('test1');
    }
    // 接聽服務器發回的信息並處理展示
    ws.onmessage = function (data) {
        console.log('接收到來自服務器的消息:');
        console.log(data);
        //完成通信後關閉WebSocket連接
        ws.close();
    }
    // 監聽連接關閉事件
    ws.onclose = function () {
        // 監聽整個過程中websocket的狀態
        console.log('ws連接狀態:' + ws.readyState);
    }
    // 監聽並處理error事件
    ws.onerror = function (error) {
        console.log(error);
    }
    function sendMessage() {
        var content = $("#message").val();
        $.ajax({
            url: '/socket/publish?userId=10086&message=' + content,
            type: 'GET',
            data: { "id": "7777", "content": content },
            success: function (data) {
                console.log(data)
            }
        })
    }
</script>

頁面初始化建立websocket連接,之後就可以進行雙向通信瞭,效果還不錯

>

自定義推送

上邊我們給我出瞭6種方案的原理和代碼實現,但在實際業務開發過程中,不能盲目的直接拿過來用,還是要結合自身系統業務的特點和實際場景來選擇合適的方案。

推送最直接的方式就是使用第三推送平臺,畢竟錢能解決的需求都不是問題,無需復雜的開發運維,直接可以使用,省時、省力、省心,像goEasy、極光推送都是很不錯的三方服務商。

一般大型公司都有自研的消息推送平臺,像我們本次實現的web站內信隻是平臺上的一個觸點而已,短信、郵件、微信公眾號、小程序凡是可以觸達到用戶的渠道都可以接入進來。

消息推送系統內部是相當復雜的,諸如消息內容的維護審核、圈定推送人群、觸達過濾攔截(推送的規則頻次、時段、數量、黑白名單、關鍵詞等等)、推送失敗補償非常多的模塊,技術上涉及到大數據量、高並發的場景也很多。所以我們今天的實現方式在這個龐大的系統面前隻是小打小鬧。

Github地址

文中所提到的案例我都一一的做瞭實現,整理放在瞭Github上,覺得有用就 Star 一下吧!

傳送門:github.com/chengxy-nds…

以上就是java實現web實時消息推送的七種方案的詳細內容,更多關於java web實時消息推送的資料請關註WalkonNet其它相關文章!

推薦閱讀: