java消息推送,一个实时数据的web显示该怎么做
javaweb消息实时推送可以使用GoEasy平台。
操作如下:
到goeasy官网上注册一个账号,并创建一个应用,应用创建好后系统会默认为它生成两个key: publish key和subscribe key。
前台实时订阅及接收:需要引入goeasy.js,然后调用goeasy的subscribe方法订阅一个channel即可,订阅时无论是用publish key还是subscribe key都可以。通过subscribe的参数 onMessage的回调函数可以实时接收到消息。
前台实时推送:需要引入goeasy.js(如果该页面已经引入了可不在引入),然后调用goeasy的publish方法向已订阅的channel上推送消息即可,推送时只能用publish key。
后台实时推送:调用GoEasy Restful API, 用post方式访问http://goeasy.io/goeasy/publish, 同时还需要带上三个必要参数:
appkey: publish key
channel: 你订阅了的channel
content: 推送内容
GoEasy的实现原理很简单,就是推送消息的一端只负责推送,而需要接收的页面需要预先订阅。订阅什么呢?订阅channel。往 某个channel上推送消息,客户端就订阅相同的channel,这样就可以确保准确接收。通过channel我们可以自己指定哪些页面或哪些用户可以 接收到从这个channel上推送出来的消息。
这些场景本身属于一类称为 “服务器推送” 的问题。通常,服务器是中心实体,服务器将首先获得关于所发生的任何更改的通知,服务器负责将此类更改通知所有连接的客户端。但遗憾的是,HTTP 是客户端-服务器通信的标准协议,它是无状态的,而且在某种意义上来说,也是一种单向的协议。HTTP 场景中的所有通信都必须由客户端发起,至服务器结束,然而我们所提到的场景的需求则完全相反。对于服务器推送来说,需要由服务器发起通信,并向客户端发送数据。HTTP 协议并无相关配置,Web 站点应用程序开发人员使用独创的方法来绕过这些问题,例如轮询,客户端会以固定(或可配置)的时间间隔与服务器联系,查找是否有新更新可用。在大多数时候,这些轮询纯粹是浪费,因而服务器没有任何更新。这种方法不是没有代价的,它有两大主要问题。
这种方法极度浪费网络资源。每一个轮询请求通常都会创建一个 TCP 套接字连接(除非 HTTP 1.1 将自己的keepAlive 设置为 true,此时将使用之前创建的套接字)。套接字连接本身代价极高。除此之外,每一次请求都要在网络上传输一些数据,如果请求未在服务器上发现任何更新,那么这样的数据传输就是浪费资源。如果在客户端机器上还运行着其他应用程序,那么这些轮询会减少传输数据可用的带宽。
即便是请求成功,确实为客户端传回了更新,考虑到轮询的频率,这样的更新也不是实时的。例如,假设轮询配置为每 20 秒一次,就在一次请求刚刚从服务器返回时,发生了更新。那么这次更新将在 20 秒后的下一次请求到来时才能返回客户端。因而,服务器上准备好供客户端使用的更新必须等待一段时间,才能真正地为客户端所用。对于需要以尽可能实时的方式运行的应用程序来说,这样的等待是不可接受的。
考虑到这样两个问题,对于需要关键、实时的服务器端更新的企业应用程序而言,轮询并不是最理想的方法。在这篇文章中,我将介绍多种可以替代轮询的方法。每一种替代方法在某些场景中都有自己的突出之处。我将说明这些场景,并展示需要实时服务器推送的一组 UI。
Ajax 应用程序中的服务器更新技术
让我们来具体看看用于更新来自服务器的信息的一些常用技术,这些技术模拟了服务器推送。
短轮询
短轮询也称为高频轮询,就是我在本文开头处介绍的技术。这种方法在以下情况中表现最好:
有足够的带宽可用。
根据统计数据,大多数时候,请求都能获得更新。例如,股市数据就总是有可用更新。
使用 HTTP 1.1 协议。设置 keepAlive=true,因而,同一个套接字连接始终保持活动状态,并可重用。
长轮询
长轮询是用于更新服务器数据的另外一种方法。这种方法的理念就是客户端建立连接,服务器阻塞连接(通过使请求线程在某些条件下处于等待状态),有数据可用时,服务器将通过阻塞的连接发送数据,随后关闭连接。客户端在接收到更新后,立即重新建立连接,服务器重复上述过程,以此实现近于实时的通信。然而,长轮询具有以下缺陷:
一般的浏览器默认允许每台服务器具有两个连接。在这种情况下,一个连接始终是繁忙状态。因而,UI 只有一个连接(也就是说,能力减半)可用于为用户请求提供服务。这可能会导致某些操作的性能降低。
仍然需要打开和关闭 HTTP 连接,如果采用的是非持久连接模式(keepAlive=false),那么这种方法的代价可能极高。
这种方法近于实时,但并非真正的实时。(当然,某些外部因素总是不可控的,比如网络延时,在任何方法中都会存在这些因素。)
流通道
流通道(streaming channel)与长轮询大致相同,差别在于服务器不会关闭响应流。而是特意保持其处于打开状态,使浏览器认为还有更多数据即将到来。但是,流通道也有着自己的缺陷:
最大的问题就是数据刷新(flushing)。过去,Web 服务器会缓存响应数据,仅在接受到足够的字节数或块数后才会发送出去。在这种情况下,即便应用程序刷新数据,也仍然会由服务器缓存,以实现优化。更糟的是,如果在客户端和服务器之间存在代理服务器,那么代理也可能会为自身之便缓存数据。
如果发现套接字将打开较长的时间,某些浏览器实现可能会自行决定关闭套接字。在这种情况下,通道需要重新建立。
通常,第一个问题可通过为每个流响应附加垃圾有效载荷来解决,使响应数据足以填满缓冲区。第二个问题可通过“保持活动” 或按固定间隔 “同步” 消息来欺瞒浏览器,使浏览器认为数据是以较慢的速率传入的。
这些解决方案适用的用例范围狭窄。所有这些方法都已经在 Internet 上的某些解决方案中得到了应用。然而,这些解决方案都遭遇了相同的问题:缺乏可伸缩性。典型情况下,要阻塞一个请求,需要阻塞处理请求的线程,因为如今几乎所有应用服务器都会执行阻塞 I/O。即便不是这样,Java™ 2 Platform, Enterprise Edition (J2EE) 也未提供为 HTTP 请求和响应执行非阻塞 I/O 的标准。(Servlets 3.0 API 可解决这一问题,因为这些 API 中包含Comet Servlet。)
至此,需要具备非阻塞 I/O(NIO)服务器,客户端应用程序通过它进行连接。由于此类套接字是纯 TCP 二进制套接字,因而将实现以下目标:
由于服务器端具有 NIO,因而可实现更高的可伸缩性。
响应缓存的问题不复存在,因为这个套接字直接受应用程序的控制。
基于上述说明,有必要指出这种方法的四个缺点:
由于使用的是二进制 TCP 套接字,因而应用程序无法真正地利用 HTTPS 层提供的 SSL 安全性。所以,要求数据安全性的应用程序可能需要提供自己的加密工具。
通常情况下,服务器套接字将在 80 以外的端口上运行,如果防火墙仅允许来自端口 80 的流量,将出现问题。因而,可能需要进行一些端口配置。
Ajax 客户端无法通过后端打开 TCP 套接字连接。
即便 Ajax 客户端能够执行 open 函数,也无法理解二进制内容,这是因为 Ajax 使用的是 XML 或 JSON(基于文本)格式。
在这篇文章中,要强调的是如何真正地绕开第三个和第四个问题。如果能够处理安全性和防火墙问题,那么其他问题也能得到处理。这种做法的获益极为显著。
可为应用程序实现最大程度的实时服务器推送行为(不考虑网络延时等外部因素),将获得高度可伸缩的解决方案(以同时连接的客户端数量为准)。
下面解决上述的第三个和第四个问题。
基于套接字的 RIA 技术
Ajax 并不能真正地解决第三个和第四个问题。因而,需要利用其他 RIA 技术寻求解决方案。有两种 RIA 技术提供的套接字 API 可与 Ajax 应用程序交互。这两种技术是 Adobe Flex 和 OpenLaszlo。全面介绍这两种技术并非本文讨论范围之内,但这些技术提供的两种特性如下所示:
均能通过后端打开 TCP 二进制套接字
均能出色地与运行在同一个浏览器窗口中的 Ajax 应用程序(主要是 JavaScript)交互
但这仅仅解决了部分问题。确实可以打开套接字,可以使 Ajax 应用程序使用它们,但 Ajax 应用程序仍然无法处理纯二进制数据。实际上,这两种技术都提供了二进制 TCP 套接字的一种变体,称为XMLSocket,它可用于来回传输纯 XML 数据。这正是您需要的东西。如果这些技术能够通过服务器打开套接字,如果它们能够传输 XML 数据,任务就完成了。Ajax 应用程序可充分利用这一点,模拟实时服务器推送技术。下面将介绍如何实现。
实现 Ajax 服务器推送
将使用两种工具解释这项技术:Adobe Flex 和 OpenLaszlo。首先,需要编写能够接收并缓存连接的后端服务器。在这里不能太过偏离主题,因而要保证服务器基于阻塞 I/O。
需要创建一个服务器套接字,接收预先指定地址的连接:
清单 1. 创建服务器套接字
public class SimpleServer {
public static void main(String[] args) throws IOException {
ServerSocket serverSocket = new ServerSocket();
serverSocket.bind(new InetSocketAddress("localhost",20340));
Socket socket = serverSocket.accept();
}
}