开发一个网络应用时，通常情况下是客户端发送请求服务端相应，tigger 在客户端。但如果需要一个服务端 tigger 并通知客户端的机制，则可以考虑以下实现方案。
方案一：Ajax Polling
- 客户端在页面上执行一段 JS，每过固定间隔（比如 0.5s）请求服务端上的某个文件
- 服务端立即响应每一次请求
缺点： 这是一种简单的轮询方式，但会导致不必要的请求，即使在没有新通知的情况下也会消耗资源。适用于实时性不是很关键的场景。
方案二：Ajax Long-Polling
- 客户端在页面上执行一段 JS，请求服务端上的某个文件
- 服务端不会立即响应，而是等待触发条件再响应
- 客户端收到响应并处理后，立即再次发起请求，重启这个过程
缺点： Long-Polling 是对轮询方式的改进，可以减少不必要的请求。然而，长时间保持连接可能导致代理服务器或防火墙超时，而且客户端需要处理连接超时和重连逻辑。
方案三：Server Sent Events (SSE) / EventSource
使用 HTTP 持久连接，满足服务端到客户端的实时通讯
- 客户端在页面上执行一段 JS，开启一个面向服务器的长连接
- 服务端等待触发条件，再向客户端发送事件。服务端需要有一个事件循环
缺点：SSE 是一种更有效的方式来实现服务器向客户端推送数据。它允许服务器在单个连接上持续发送事件，客户端通过 EventSource API 接收这些事件。这在一些实时通知场景中非常有用，但可能在一些浏览器中不支持。
方案四：Websockets
使用 WebSocket 协议，满足客户端与服务端的双向实时通讯
- 客户端在页面上执行一段 JS，开启一个面向服务器的长连接
- 客户端和服务端现在可以双向地发送数据。服务端需要有一个事件循环
类似 HTTP，WebSocket 也是一个应用层协议，也是通过 TCP 通信。但和 HTTP 不同的是，它是全双工（full-duplex）通信，也就是说客户端和服务端可以双向通信。
WebSocket 是一种强大的通信协议，适用于需要双向实时通信的场景。它的优势在于可以在单个连接上进行双向通信，而且可以支持复杂的消息交换。但需要考虑一些状态管理和错误处理的问题，以确保连接的稳定性和安全性。
可以使用第三方的 WebSocket 服务器（Pusher，一个 SaaS 产品）或者开源的 WebSocket 框架（socket.io），这样就只用实现客户端，非常省力！
