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上推送出来的消息。
温馨提示：内容为网友见解，仅供参考
第1个回答 2017-01-16
使用ajax轮询或反向ajax
第2个回答 2017-01-14
Ajax 技术已经存在了一段时间，开发的动力已经真正开始得到了人们的认可。越来越多的 Web 站点正在考虑使用Ajax 进行设计，开发人员也开始将 Ajax 的能力发挥到极限。随着社交网络和协作式报告等现象的出现，一组全新的要求浮现出来。如果有其他用户更改了某位用户正在观察的任何活动，则用户希望得到通知。如果一个 Web 站点显示动态数据，如股价等，那么所有用户都必须立即得到关于变更的通知。
这些场景本身属于一类称为 “服务器推送” 的问题。通常，服务器是中心实体，服务器将首先获得关于所发生的任何更改的通知，服务器负责将此类更改通知所有连接的客户端。但遗憾的是，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();
}
}
这些场景本身属于一类称为 “服务器推送” 的问题。通常，服务器是中心实体，服务器将首先获得关于所发生的任何更改的通知，服务器负责将此类更改通知所有连接的客户端。但遗憾的是，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();
}
}
相似回答
