事件驱动架构（WebSocket、Pub/Sub等）：客户端与服务端如何感知新消息？

一、WebSocket的消息感知逻辑 #

• WebSocket建立的是TCP层的持久双向连接，一旦连接成功，客户端和服务端的网络套接字（Socket）都处于监听状态，而非客户端主动发起周期性查询。
• 当服务端有新消息需要发送时，直接通过已建立的TCP连接将数据包推送给客户端，操作系统的网络栈会负责将数据投递到客户端的Socket。
• 客户端侧的WebSocket API（比如浏览器中的WebSocket对象）会通过onmessage回调被动接收消息，无需开发者编写定时查询的逻辑。举个简单的前端代码示例：

  const ws = new WebSocket('ws://your-server.com/chat');
  ws.onmessage = (event) => {
    console.log('收到新消息:', event.data);
  };
  

  这个回调会在服务端推送消息时自动触发，完全不需要轮询。

二、Pub/Sub架构的消息推送机制 #

Pub/Sub的核心是**消息代理（Broker）**负责消息的路由，不同实现的底层逻辑略有差异，但都不是依赖订阅者轮询：

• 实时场景下的长连接Pub/Sub（比如基于WebSocket的聊天、通知系统）：
  订阅者通过WebSocket与Broker建立持久连接，Broker会维护「主题-订阅者连接」的映射表。当发布者向某个主题推送消息时，Broker会直接遍历该主题对应的所有订阅者连接，将消息主动推送给订阅者，订阅者通过WebSocket的onmessage回调接收消息。
• 基于消息队列的Pub/Sub（比如RabbitMQ、Kafka）：
  订阅者（通常是后端服务）与Broker建立TCP长连接（遵循AMQP、Kafka协议等），Broker在检测到对应主题有新消息时，会主动将消息推送给订阅者的连接。部分场景下可能会使用「长轮询（Long Polling）」替代纯推送：订阅者发起请求后，Broker会hold住请求直到有消息返回，或超时后再重试，这种方式比短轮询高效得多，但本质还是服务端主动触发响应，而非订阅者频繁查询。

总结 #

不管是WebSocket还是主流的Pub/Sub实现，核心都是服务端/消息代理主动推送消息，订阅者或客户端只需要监听连接上的消息事件即可，完全不需要持续短轮询。短轮询是早期缺乏持久连接技术时的折中方案，现在已经被更高效的推送机制取代。

内容的提问来源于stack exchange，提问作者Drew Gallagher