個人覺得最簡單的是用短輪詢方式：

前臺發(fā)送請求A，調(diào)用后臺方法，后臺方法啟動任務(wù)后返回結(jié)果。拿到結(jié)果后，前臺定期（1s）通過請求B查詢后臺任務(wù)是否處理完成。

只能再給一個接口去輪詢了，服務(wù)器又不能直接給客戶端發(fā) http 請求。

輪詢也可以，要不前臺和后臺建立WebSocket連接，數(shù)據(jù)處理好之后，服務(wù)端向客戶端直接推送反饋信息。

WebSockets can make a web page dynamic and interactive. However in many cases a combination of Ajax and HTTP streaming and/or long polling could provide a simple and effective solution.

For example news, mail, and social feeds need to update dynamically but it may be perfectly okay to do so every few minutes. Collaboration, games, and financial apps on the other hand need to be much closer to real time.

Latency alone is not a deciding factor. If the volume of messages is relatively low (e.g. monitoring network failures) HTTP streaming or polling may provide an effective solution. It is the combination of low latency, high frequency and high volume that make the best case for the use WebSocket.

看了springboot websocket文檔說的，什么時候用輪詢，什么時候用websocket說得很清楚，我還是乖乖的用輪詢吧