WEB实时推送有哪些实现方案？

现在确实有不少这样的场景，当后台数据发生变化，需要主动“通知”前台进行页面刷新，实现方案有这么几种：

轮询

很容易理解，实现起来也非常简单的一种方法：客户端每隔一段时间向后台发送一次请求，把最新的数据取回来。

当然缺点也比较明显，如果定时任务的时间设置比较长，那么数据更新和展示会不及时；如果定时任务的时间设置的比较短，那么频繁地访问后台，也会增加后台服务器的压力。

长轮询

如果是轮询的话，客户端每次向后台请求数据的时候，都会建立一次连接；而长轮询，客户端发送请求给服务器之后，如果有最新数据的话，就直接返回，如果没有最新数据的话，就等待，当有新数据的时候再返回。

缺点也显而易见，因为保持连接也是会消耗资源的，并且如果长时间没有新数据的话，也会发生超时。

Iframe

这个方式的本质是基于Iframe的>

维护长链接就需要增加开销，而且需要考虑连接中断、重连等问题。

WebSocket

>

WebSocket，是要在客户端和服务器之间，建立一个通道，建立一个真的长链接；一旦确立WebSocket通信连接，不论服务器还是客户端，任意一方都可直接向对方发送数据，这个是真正意义的双向通信；并且数据格式可以是文本，也可以是二进制数据。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

其实，在服务器的选择上很广，基本上，主流语言都有WebSocket的服务器端实现，而我们作为前端开发工程师，当然要选择现在比较火热的NodeJS作为我们的服务器端环境了。
NodeJS本身并没有原生的WebSocket支持，但是有第三方的实现（大家要是有兴趣的话，完全可以参考WebSocket协议来做自己的实现），我们选择了“ws”作为我们的服务器端实现。
由于本文的重点是讲解WebSocket，所以，对于NodeJS不做过多的介绍，不太熟悉的朋友可以去参考NodeJS入门指南（>

疯狂创客圈 Java 高并发 亿级流量聊天室实战实战系列 博客园总入口

架构师成长+面试必备之 高并发基础书籍 Netty Zookeeper Redis 高并发实战

很多项目，都需要基于 Websocket 协议做在线客服、在线推送、在线聊天，虽然 Tomcat 内置支持 Websocket 协议，但是由于 Tomcat 的吞吐量、连接数都很低，作为测试是可以的。 在生产环境，一定需要使用高吞吐量、高连接数的 Netty 服务器进行替代 。

之所以 Netty 性能高，因为其使用的是 Reactor 反应器模式。关于反应器模式原理，请参见 《Netty Zookeeper Redis 高并发实战》 一书。

聊天过程gif 演示：

聊天示意图：

Netty搭建的服务器基本上都是差不多的写法：

绑定主线程组和工作线程组，这部分对应架构图中的事件循环组。其原理，，请参见 《Netty Zookeeper Redis 高并发实战》 一书。

重点就是ChannelInitializer的配置，以异步的方式启动，最后是结束的时候关闭线程组。

下面是用websocket做聊天室的逻辑：

源码网址： Java 高并发研习社群 博客园 总入口

疯狂创客圈 经典图书 ： 《Netty Zookeeper Redis 高并发实战》 面试必备 + 面试必备 + 面试必备

小程序即时通讯的开发需要结合小程序原生框架和即时通讯SDK来实现。以下是一般的开发流程：
1 注册即时通讯SDK：需要注册即时通讯SDK并获取开发所需的AppID等信息。
2 集成SDK：将SDK文件导入到小程序项目并进行集成。根据所用 SDK 的类库不同，可能需要使用 npm 进行安装并引入。
3 登录接口集成：根据SDK提供的接口，开发者可实现用户登录/注销等 *** 作，用自己的用户系统进行绑定。
4 消息接口集成：开发者可以根据用户需要自定义消息类型和格式，实现文字、、音视频等元素的消息发送和接收。
5 消息管理：为了更好地处理和管理消息，还需要建立一个消息管理系统，例如处理未读消息提醒、消息的存储和同步等。
开发小程序即时通讯并不简单，需要掌握前端基本技能和后端技术。需要具备 JavaScript 的基本语法和逻辑思维能力，了解常用UI组件库，熟悉小程序原生框架的使用方法，并对 WebSocket 等通信技术有较深的了解能力。对于后端技术，需要掌握服务器架构和 *** 作系统的基础知识，了解即时通讯技术中的一些基本概念如IM即时通讯协议等。
综上，需要一定的编程实力，所以小程序即时通讯的开发可能不是那么容易，需要具备一定的技术水平和实践经验来完成。

如果您的Web应用程序中进行了数据改动，并且需要通知其他程序，可以考虑以下几种方式：
1 使用消息队列：将数据改动信息发送到一个消息队列中，其他程序从该队列中获取并处理相应的消息。这种方式可以实现异步通信，避免因为某个服务不可用而导致整个系统崩溃。
2 使用RESTful API：在Web应用程序中提供一组API接口，其他程序通过调用这些接口来获取最新的数据。当有新的数据更新时，Web应用程序会自动推送给已经订阅该API接口的客户端。
3 使用WebSocket：WebSocket是一种全双工协议，在建立连接后可以实现服务器主动向客户端推送信息。使用WebSocket技术可以实现实时通信和即时响应。
4 定期轮询：在Web应用程序中定期检查是否有新的数据更新，并将其发送给其他相关程序。但是这种方式可能会增加服务器负担，并且无法保证及时性。
综上所述，选择何种方式取决于具体情况和需求。根据业务场景、系统架构等方面进行综合评估后再做出选择。

我于2014年开启即时通讯的开发之路，历经从服务端到客户端，从第三方到自研，经历过诸多的研发难题，都一一破解。现将经验总结如下，希望对行业内从事IM开发的程序员有所帮助。

①P2P方式

P2P方式多用于局域网内聊天，这种方式在有种种限制和不便。一方面它只适合在线的点对点消息传输，对离线，群组等支持不够。另一方面由于 NAT 的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。使用P2P方式的软件在启动后一般做两件事情：

1、进行UDP广播:发送自己信息和接受同局域网内其他端信息。

2、开启TCP监听:等待其他端进行连接。

②服务器中转方式

大部分的互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，具有有以下的优点:

1、支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室。

2、方便业务逻辑的拓展和新旧版本的兼容，当然它也有自己的问题，就是服务器架构复杂，并发要求高。

通过以上的比较，建议我们在开发IM系统的时候使用服务器中转的方式。

IM的网络连接方式有基于TCP的长连接和基于>