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、分布式等视频资料