B/S系统消息推送的多种实现方式
在B/S系统中消息推送是一个很常见的功能，不管是点对点推送，还是广播推送。由于B/S架构多采用HTTP协议，该协议是基于请求/响应模式的，不能做到主动向客户端发送数据，我们可以通过伪推送或者借助第三方通信来进行实时推送。下面就是一些常见的推送方式，项目中具体采用哪一种方式，还要从项目中对该消息时效性的要求、浏览器兼容性、是否需要双工通信、开发难度等等角度考虑。
拉取式
服务器发送消息即在消息表中增加一条数据，客户端主动请求消息接口，才会获取到新消息。
优点：后端编程简单，资源浪费最少
缺点：时效性最差
场景：对时效性没要求的小型应用
短轮询
客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息，并关闭连接。
优点：后端编程还是简单，时效性由轮询时间长短决定
缺点：频繁发送大量无用请求，浪费带宽和服务器资源，页面可能出现假死
场景：客户端数量少的小型应用
长轮询
客户端向服务器发送Ajax请求，服务器会阻塞请求不会立刻返回，直到有数据或者超时才返回客户端，然后关闭连接。客户端处理完响应消息后再向服务器发送新的请求。
优点：相对于短轮询来说，减少了大量无用请求次数，减少网络流量
缺点：服务器挂着大量连接浪费资源
场景：客户端连接少的应用、网页版聊天软件
长连接
在页面中插入一个隐藏的iframe，利用其src属性在服务器和客户端之间创建一条长连接，服务器向iframe传输数据（通常是HTML，内有负责插入信息的javascript），来实时更新页面。
优点：消息及时到达，不发无用的请求
缺点：服务器维护一个长连接会增加开销
场景：Gmail聊天
SSE(Server-Sent Events)
SSE与长连接机制类似，客户端发送一个请求，服务端保持这个连接直到有新消息发送回客户端，仍然保持着连接，这样连接就可以消息的再次发送，由服务器单向发送给客户端。SSE本质是发送的不是一次性的数据包，而是一个数据流。可以使用 HTTP 301 和 307 重定向与正常的 HTTP 请求一样。服务端连续不断的发送，客户端不会关闭连接，如果连接断开，浏览器会尝试重新连接。如果连接被关闭，客户端可以被告知使用 HTTP 204 无内容响应代码停止重新连接。
优点：SSE 使用 HTTP 协议，现有的服务器软件都支持，属于轻量级，使用简单，默认支持断线重连
缺点：长期占用一个连接，一般只用来传送文本，二进制数据需要编码后传送
场景：服务器向客户端单向实时通信
WebSocket
WebSocket是一种全新的协议，随着H5草案的不断完善，越来越多的现代浏览器开始全面支持WebSocket技术了，它将TCP的Socket（套接字）应用在了WebPage上，从而使通信双方建立起一个保持在活动状态连接通道。WebSocket是纯事件驱动的，一旦 WebSocket 连接建立后，通过监听事件可以处理到来的数据和改变的连接状态。数据都以帧序列的形式传输。服务端发送数据后，消息和事件会异步到达。WebSocket编程遵循一个异步编程模型，只需要对WebSocket对象增加回调函数就可以监听事件。
优点：全双工通信、资源开销小、安全性高、有一定可扩展性
缺点：传输数据需要进行二次解析，增加开发成本及难度
场景：网络游戏、银行交互、支付
WebSocket+消息中间件(Redis|RabbitMQ)
由于WebSocket是长连接，Session保持在一个Server中，所以在不同Server在使用WebSocket推送消息时就需要获取对应的Session进行推送，在分布式系统中就无法获取到所有Session，这里就需要使用一个中间件将消息推送到各个系统中，并发量少、消息要求不严格时可以使用redis的sub/pub功能；如果需要更多特性，比如断开重连、发布确认等等高级消息队列功能，可以使用专门的中间件比如RabbitMQ、RocketMQ