24khandsome's Blog

24khandsome's Blog

消息推送系列01-消息推送常规方案概述

发表于 分类于
消息推送常规方案概述,轮询、长链接、SSE、Websocket、MQTT等

消息推送方案概述

​ 在传统的Web架构中，通信是由客户端主动发起的（Request-Response）。但对于需要服务器主动向客户端推送数据的场景（如消息提醒、实时数据监控），传统的模式不再适用。由此诞生了多种“服务器推送”技术。

短轮询 (Short Polling)

核心思想：客户端定期向服务器发送HTTP请求，询问是否有新消息。“有就问，没有也问”。

工作流程：

  1. 客户端发起一个普通的HTTP Request。
  2. 服务器立即响应（Response），即使没有新数据。
  3. 客户端等待一个固定的时间间隔（Interval），重复步骤1。

图示：

deepseek_mermaid_20250831_8befde

特点：

  • 优点：实现非常简单，无需服务器做特殊处理。
  • 缺点：
    • 高延迟：消息到达的实时性取决于轮询间隔。
    • 高开销：大量无效请求（无数据也请求），浪费服务器和网络资源。
  • 适用场景：几乎被淘汰，仅用于一些非常简单的、实时性要求极低的场景。

长轮询 (Long Polling)

核心思想：客户端发起请求，如果服务器没有新数据，就保持这个连接挂起（Hang），直到有数据或超时为止。“不问则已，一问就等到有消息或超时”。

工作流程：

  1. 客户端发起一个HTTP Request。
  2. 服务器收到请求，如果无新数据，不立即响应，而是hold住这个连接。
  3. 一旦有数据到达或请求超时，服务器返回响应。
  4. 客户端收到响应后，立即发起一个新的请求，循环往复。

图示：

image-20250831170441992

特点：

  • 优点：比短轮询实时性高，减少了大量无效请求。
  • 缺点：
    • 服务器资源占用：每个挂起的连接都占用一个服务器线程/连接，高并发时对服务器压力大。
    • 复杂性：需要服务器有处理大量并发连接的能力。
  • 适用场景：早期实现实时Web应用的常见手段，如Web版聊天室。

Server-Sent Events (SSE)

核心思想：基于HTTP的单向服务器推送技术。客户端发起一个请求，服务器可以通过这个连接持续地、主动地发送数据流给客户端。

工作流程：

  1. 客户端使用EventSource API向服务器建立一个持久连接。
  2. 服务器保持连接打开，并以一种特定的 text/event-stream 格式持续发送数据块。
  3. 数据流可以包含不同的事件类型，客户端可以监听处理。

图示：

image-20250831170853344

特点：

  • 优点：
    • 标准HTTP：无需额外协议，支持断线重连（Retry机制）。
    • 单向高效：非常适合服务器向客户端推送实时数据流，如股票行情、新闻推送、实时日志。
  • 缺点：单向通信，客户端无法通过此连接向服务器发送数据（需额外AJAX请求）。
  • 适用场景： dashboard、实时监控、消息通知流。

WebSocket

核心思想：在单个TCP连接上提供全双工（Full-Duplex） 通信的协议。客户端和服务器可以平等地、主动地随时向对方发送数据。

工作流程：

  1. 客户端发起一个HTTP请求，并带上Upgrade: websocket等头信息，请求协议升级。
  2. 服务器同意升级，返回101 Switching Protocols响应。此时，HTTP连接被升级为WebSocket连接。
  3. 此后，双方通过这个持久化的连接，以WebSocket数据帧（Frames）的形式进行双向通信。

图示：

image-20250831171251738

特点：

  • 优点：
    • 真正双向实时通信：延迟极低，性能高。
    • 高效：数据帧头很小，减少传输开销。
  • 缺点：需要服务器和客户端都支持WebSocket协议，相对于SSE更复杂一些。
  • 适用场景：互动性强的实时应用，如网页游戏、协同编辑、实时聊天、金融交易终端。

MQTT

核心思想：一种基于发布/订阅（Pub/Sub） 模式的轻量级消息传输协议。它不是HTTP，是为物联网（IoT）和不稳定网络设计的。

工作流程：

  1. 设备（客户端）与MQTT Broker（消息代理服务器）建立TCP连接。
  2. 客户端向Broker订阅（Subscribe） 它关心的主题（Topic）（如 sensor/temperature）。
  3. 另一个客户端向Broker的同一个Topic发布（Publish） 一条消息。
  4. Broker负责将消息转发给所有订阅了该Topic的客户端。

图示：

image-20250831171708749

特点：

  • 优点：
    • 极低功耗和带宽消耗：协议开销极小。
    • 支持不稳定网络：提供多种服务质量（QoS）级别保证消息必达。
    • 解耦：发布者和订阅者不需要知道彼此的存在。
  • 缺点：需要部署和维护额外的MQTT Broker组件。
  • 适用场景：物联网（IoT）、移动消息推送（如App推送后台）、M2M通信。

方案对比

方式 通信模式 协议 优点 缺点 适用场景
短轮询 客户端拉取 HTTP 简单 延迟高、资源浪费 基本淘汰
长轮询 客户端拉取 HTTP 实时性较好 服务器资源占用高 早期实时Web应用
SSE 服务器推送 HTTP 单向流式推送、简单 单向 实时数据流、通知
WebSocket 双向实时 WS 低延迟、全双工 需协议升级 互动应用（聊天、游戏）
MQTT 发布/订阅 MQTT 轻量、省电、解耦 需Broker IoT、移动推送

RabbitMQ可以当做MQTT的broker吗

MQTT与常见的MQ中间件RabbitMQ的区别

  • RabbitMQ 本身是一个消息代理（Message Broker），它最初实现的是 AMQP (Advanced Message Queuing Protocol) 协议。AMQP 是一个为企业级应用设计的、功能丰富的消息队列协议。
  • MQTT 是另一种专门为物联网（IoT）设计的轻量级消息协议。

RabbitMQ 理解为一个支持多种插件的消息引擎核心，而 AMQP、MQTT、STOMP 等则是这个引擎可以理解的不同的“语言”或“方言”。

默认情况下，RabbitMQ 只“说” AMQP 这一种语言。要让它能听懂并“说” MQTT，就需要安装一个“翻译官”——也就是 rabbitmq_mqtt 插件。

缺点与限制：

  • 非专为IoT优化：RabbitMQ的核心设计并非为海量低功耗设备而生。相比于专业的MQTT Broker（如 EMQX、HiveMQ），其在连接数（数十万级别 vs 百万级别）、分布式集群、对MQTT 5.0支持完整性等方面可能有所欠缺。
  • 功能差异：不支持MQTT的某些高级特性（如《遗嘱消息》的retain标志在RabbitMQ中处理方式不同）。
  • 性能开销：协议转换会带来额外的开销。

结论与建议

  • 可以吗？ 可以，通过安装 rabbitmq_mqtt 插件，RabbitMQ 能成为一个非常优秀的 MQTT Broker。
  • 应该吗？ 这取决于你的场景：
    • 适合：设备量不大（例如万级别以下）、需要与现有RabbitMQ系统集成、快速验证概念的场景。
    • 不适合：需要连接海量物联网设备（百万级）、需要用到完整的MQTT 5.0特性、追求极致轻量和性能的纯IoT场景。在这种情况下，你应该选择专业的MQTT Broker，如 EMQX、Mosquitto 或 HiveMQ。