摘要：早期网站仅展示静态内容，而如今我们更期望：实时更新、即时聊天、通知推送和动态仪表盘。
早期网站仅展示静态内容，而如今我们更期望：实时更新、即时聊天、通知推送和动态仪表盘。
那么要如何实现实时的用户体验呢？三大经典技术各显神通：
• SSE（Server-Sent Events）：轻量级单向数据流• WebSocket：双向全双工通信• Long Polling（长轮询）：传统过渡方案假设目前有三个业务场景，需要实现数据实时更新：
• 股票交易仪表盘• 即时聊天平台• 实时新闻推送面对这些需求，我们应该如何决策选择合适的方案呢？
客户端持续询问服务器：
• “有更新吗？”• “没有”• “现在呢？”• “还是没有”• “现在呢？”• “有了！”就像在吃饭排队叫号的时候，站在店门口每隔5分钟询问是否到你一样，效率低下。
@GetMapping("/updates")public ResponseEntitygetUpdate{
// 模拟延迟或等待事件
return ResponseEntity.ok("最新更新！");
}
✔ 优点:
• 实现简单（标准REST）• 兼容性最佳✘ 缺点:
• 高延迟• 资源浪费（大量空请求）• 扩展性差客户端建立连接后：
• “持续监听中…”• 服务器随时推送：• “新事件1”• “新事件2”• “连接保持”仅支持服务器到客户端的单向通信，适合实时数据流。
@GetMapping("/stream")public SseEmitter stream{
SseEmitter emitter = newSseEmitter;
// 异步推送更新
emitter.send("实时更新！");
return emitter;
}
✔ 优点:
• 轻量（基于HTTP/1.1）• 兼容多数代理• 自动重连机制✘ 缺点:
• 单向通信• 部分环境支持有限• 控制粒度较粗适用场景需要简单高效的服务器到客户端更新（如：股票行情、实时比分、状态仪表盘、监控系统等）。
建立双向通道实现实时对话：
• 服务器：”Bob有新消息”• 客户端：”收到！….”类似对讲机的全双工通信模式。
@Configuration@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
public voidregisterWebSocketHandlers(WebSocketHandlerRegistry registry){
registry.addHandler(newMyHandler, "/ws").setAllowedOrigins("*");
}
}
// 处理器
public class MyHandler extends TextWebSocketHandler {
@Override
protected voidhandleTextMessage(WebSocketSession session, TextMessage message){
session.sendMessage(newTextMessage("回显：" + message.getPayload));
}
}
✔ 优点:
• 双向通信• 低延迟• 可通过消息中间件扩展✘ 缺点:
• 股票交易仪表盘：SSE• 即时聊天平台：WebSocket• 实时新闻推送（遗留系统）：Long Polling来源：码农看看一点号1
