213 lines
13 KiB
Markdown
213 lines
13 KiB
Markdown
---
|
||
tags:
|
||
- MQ
|
||
create time: 2026-05-24 19:52
|
||
update time: 2026-06-07 16:30
|
||
---
|
||
|
||
# MQ 消息协议总览
|
||
|
||
## 概述
|
||
|
||
消息协议是消息队列系统中 Producer、Broker、Consumer 之间的"通信语言"。不同的 MQ 产品使用不同的协议，协议的选择直接影响互操作性、性能和适用场景。本文梳理主流消息协议的设计定位与演进脉络。
|
||
|
||
## 正文
|
||
|
||
### 为什么需要消息协议
|
||
|
||
试想一个场景：你用 RabbitMQ 的客户端库去连接 Kafka，能成功吗？显然不能。因为它们"说的不是同一种语言"。消息协议就是定义客户端与 Broker 之间如何交换数据的规范——消息怎么编码、命令怎么发送、连接怎么建立、确认怎么回传，全都由协议约定。
|
||
|
||
协议存在的意义在于两点：**互操作性**和**标准化**。有了统一的协议，不同厂商的客户端和 Broker 可以互相通信；没有协议（或协议私有），就只能绑定在单一产品上。
|
||
|
||
> [!question]
|
||
> 如果你是一家公司的架构师，需要同时接入 RabbitMQ 和 Kafka，你会选择统一协议层还是各自接入？为什么？
|
||
|
||
> [!tip]- 架构师视角：各自接入，统一管理
|
||
> **选择各自接入（Native SDK 直连），而非统一协议层。** 核心原因：两者的设计哲学和消费范式完全不同，强行统一会同时丢失两者的核心优势。
|
||
>
|
||
> | 维度 | RabbitMQ (AMQP) | Kafka (私有协议) |
|
||
> |------|-----------------|-----------------|
|
||
> | 核心模型 | Exchange → Queue → Binding，Broker 负责路由 | Topic → Partition → Offset，Consumer 拉取 |
|
||
> | 消费模式 | Push（Broker 推送） | Pull（Consumer 主动 fetch + 提交 offset） |
|
||
> | 消息语义 | 单条 ACK/NACK/Reject，灵活路由（topic/fanout/direct） | 批量消费、基于 offset 的有序流、exactly-once 语义 |
|
||
> | 典型职责 | 任务分发、RPC、复杂路由 | 日志聚合、事件溯源、流处理 |
|
||
>
|
||
> **统一协议层的三个代价：**
|
||
> 1. **语义丢失** — Kafka 的 consumer group rebalance、事务消息等高级特性难以映射到 AMQP 模型；RabbitMQ 的死信队列、延迟队列也难以等价转换到 Topic-Partition 模型
|
||
> 2. **新增故障点** — 多一层适配/代理，意味着基础设施多一个可能出问题的地方
|
||
> 3. **性能损耗** — Kafka 协议与存储引擎深度耦合（零拷贝、mmap），加抽象必然带来开销
|
||
>
|
||
> **真正需要统一的是"管理"而非"协议"：**
|
||
>
|
||
> ```mermaid
|
||
> graph LR
|
||
> BizA["订单服务"] --> SDK["统一消息 SDK"]
|
||
> BizB["用户服务"] --> SDK
|
||
> SDK -->|"精确投递/任务分发"| RMQ["RabbitMQ"]
|
||
> SDK -->|"高吞吐日志流"| Kafka
|
||
> SDK --> Monitor["统一监控面板"]
|
||
> RMQ --> Monitor
|
||
> Kafka --> Monitor
|
||
> ```
|
||
>
|
||
> - **客户端抽象层**：对业务团队屏蔽底层差异，提供统一 `send()` / `consume()` 接口，内部按场景路由到不同 MQ
|
||
> - **统一监控运维**：消息积压、消费延迟、死信告警等统一观测
|
||
> - **统一 Schema 管理**：无论消息发到哪个 MQ，都用同一套 Schema Registry（Avro/Protobuf）保证格式一致
|
||
>
|
||
> > 各自接入、统一管理、按场景选型。协议层统一的初衷是降低复杂性，但在 RabbitMQ + Kafka 这对组合上反而增加了复杂性——因为你在试图用一种语言描述两种根本不同的消息模型。
|
||
|
||
### 协议栈层次模型
|
||
|
||
消息协议工作在应用层，底层依赖 TCP 或 WebSocket 等传输协议。层次关系如下：
|
||
|
||
```mermaid
|
||
graph TB
|
||
AppLayer["应用层协议 AMQP, MQTT, STOMP, JMS, OpenMessaging"]
|
||
TransLayer["传输层 TCP, WebSocket, TLS"]
|
||
NetLayer["网络层 IP"]
|
||
AppLayer --> TransLayer
|
||
TransLayer --> NetLayer
|
||
```
|
||
|
||
关键点：**应用层协议决定了消息的语义和格式，传输层只负责字节流的可靠传输**。这也意味着同一个应用层协议可以跑在 TCP 上（性能优先），也可以跑在 WebSocket 上（Web 场景）。
|
||
|
||
### 主流协议一览
|
||
|
||
| 协议 | 定位 | 设计目标 | 典型场景 | 代表产品 |
|
||
|------|------|----------|----------|----------|
|
||
| **AMQP 0-9-1** | 企业级消息中间件标准 | 可靠投递、灵活路由、事务支持 | 金融交易、企业集成 | RabbitMQ |
|
||
| **AMQP 1.0** | AMQP 的正式 ISO 标准版本 | 跨平台互操作、去掉 Broker 强依赖 | 云原生、跨组织通信 | Azure Service Bus, ActiveMQ |
|
||
| **MQTT** | IoT 轻量级协议 | 低带宽、低功耗、离线支持 | 物联网、移动推送 | EMQX, Mosquitto |
|
||
| **STOMP** | 简单文本协议 | 易于调试、人可读 | WebSocket 消息、简单队列 | RabbitMQ (STOMP 插件) |
|
||
| **JMS** | Java 消息服务 API 规范 | Java 生态统一编程接口 | Java 企业应用 | ActiveMQ, IBM MQ |
|
||
| **NATS** | 云原生轻量消息系统 | 极简、低延迟、原生集群 | 微服务通信、事件驱动 | NATS Server |
|
||
| **OpenMessaging** | 跨语言跨平台标准 | 云原生、厂商中立 | 多云部署 | 阿里云 RocketMQ |
|
||
| **Kafka 私有协议** | 高吞吐流处理 | 追求极致性能，协议与实现强绑定 | 日志收集、实时流计算 | Apache Kafka |
|
||
|
||
> [!question]
|
||
> 观察这张表，你会发现"标准化"和"性能优化"之间似乎存在矛盾——Kafka 放弃了标准化却获得了极致性能。你觉得这种取舍合理吗？
|
||
|
||
> [!tip]- 这种取舍是合理的，但前提是要认清"标准化"与"性能"并非二元对立
|
||
>
|
||
> **1. Kafka 的"放弃标准化"是刻意的架构决策**
|
||
>
|
||
> Kafka 的核心目标是高吞吐分布式日志流，它的私有协议之所以带来极致性能，关键在于协议与存储引擎的**深度耦合**：
|
||
> - **零拷贝传输** — 协议层直接读取磁盘上的 LogSegment，通过 `sendfile()` 跳过用户态缓冲区，数据从磁盘直达网卡
|
||
> - **基于 Offset 的消费模型** — Consumer 用 offset 直接定位到文件位置，跳过了标准化协议的"路由 → 查找 → 包装 → 返回"抽象层
|
||
> - **批量操作原生支持** — 单次请求携带整个 RecordBatch，而 AMQP 的语义设计围绕单条消息的确认/拒绝
|
||
>
|
||
> 如果 Kafka 采用标准化协议（如 AMQP），这些优化根本不可能实现——标准化意味着遵守一个与具体实现无关的抽象模型，而 Kafka 的性能恰恰来自**打破抽象边界**。
|
||
>
|
||
> **2. 但标准化的价值不能用性能衡量**
|
||
>
|
||
> | 维度 | Kafka 私有协议 | AMQP 标准协议 |
|
||
> |------|---------------|--------------|
|
||
> | 换 Broker 的成本 | 极高，客户端全部改写 | 低，换个 AMQP Broker 即可 |
|
||
> | 第三方工具生态 | 需专门适配 | 开箱即用 |
|
||
> | 厂商锁定 | 强绑定 | 弱绑定 |
|
||
>
|
||
> Kafka 能接受锁定，是因为它在日志流赛道几乎没有对手——用户为了性能愿意承担锁定成本。但通用消息中间件选私有协议几乎等于自杀，没人愿意被锁在一个没有足够生态支撑的产品上。
|
||
>
|
||
> **3. 更准确的框架：这是"专用 vs 通用"的取舍**
|
||
>
|
||
> 与其说"标准化 vs 性能"，不如说是**专用优化 vs 通用抽象**：
|
||
>
|
||
> ```
|
||
> 专用 ←————————————————→ 通用
|
||
> Kafka NATS AMQP 0-9-1 AMQP 1.0 OpenMessaging
|
||
> (极致性能) (极简) (功能丰富) (ISO标准) (跨云厂商)
|
||
> ```
|
||
>
|
||
> - 越**专用**，越能深度优化（协议与实现耦合）
|
||
> - 越**通用**，越需要抽象层（协议与实现解耦），抽象层必然带来开销
|
||
>
|
||
> Kafka 的取舍合理，是因为它**明确了自己的赛道**——它不试图成为通用消息中间件，它就是一个分布式提交日志。在这个定位下，标准化不仅没有收益，反而是一种束缚。
|
||
>
|
||
> **4. 反面案例：AMQP 1.0**
|
||
>
|
||
> AMQP 1.0 被标准化为 ISO/IEC 标准，但为了"通用"删掉了 Exchange、Queue 等核心抽象，改用 Link/Terminus 模型——结果既不兼容 AMQP 0-9-1（生态断裂），也没有明显性能提升，反而因过于复杂导致厂商采用极其缓慢。这说明：**标准化本身不是目标，生态共识才是。** 一个没人用的标准，不如一个被广泛采用的事实标准。
|
||
>
|
||
> **结论**：在明确领域做到极致（专用协议），在跨领域场景追求共识（标准化协议），两者服务不同目的。真正不合理的是在需要通用互操作的场景选私有协议（厂商锁定），或在追求极致性能的场景强行加标准化抽象（性能损耗）。
|
||
|
||
几个关键维度的直观对比：
|
||
|
||
| 维度 | AMQP 0-9-1 | MQTT | NATS | Kafka 协议 | STOMP |
|
||
|------|------------|------|------|-----------|-------|
|
||
| 最小报文 | ~8 字节 | 2 字节 | ~4 字节 | ~20 字节（Request Header） | ~4 字节（单命令） |
|
||
| 传输方式 | 二进制帧 | 二进制帧 | 纯文本命令 | 二进制自定义格式 | 纯文本帧 |
|
||
| 持久连接 | 是 | 是 | 是 | 是 | 是 |
|
||
| 消息确认 | ACK/NACK/Reject | QoS 0/1/2 | 显式 ACK（JetStream） | Offset 提交 | RECEIPT 帧 |
|
||
| 典型延迟 | 亚毫秒级 | 亚毫秒级 | 微秒级 | 毫秒级 | 亚毫秒级 |
|
||
|
||
### 协议的设计哲学差异
|
||
|
||
协议之间的差异不只是格式不同，背后是**设计哲学的分歧**：
|
||
|
||
- **AMQP** 走的是"标准化 + 丰富语义"路线。它定义了 Exchange、Queue、Binding 等抽象模型，Broker 承担了大量路由和过滤工作。好处是功能强大，代价是协议复杂。
|
||
- **MQTT** 走的是"极简 + 弱网适应"路线。协议报文最小只有 2 字节，支持 QoS 0/1/2 三级投递保障，专门为带宽受限的 IoT 设备设计。
|
||
- **Kafka** 走的是"性能优先"路线。它的私有协议直接操作文件系统的 offset，零拷贝传输，协议与存储引擎深度耦合。标准化反而会成为性能瓶颈。
|
||
- **NATS** 走的是"极简高性能"路线。协议基于纯文本命令（类似 STOMP 但更精简），默认无持久化，主打低延迟的发布订阅。Go 实现、单个二进制部署，非常适合云原生微服务场景。NATS JetStream 后来补充了持久化和流处理能力。
|
||
- **STOMP** 走的是"简单可读"路线。纯文本协议，用 `telnet` 就能手动发送消息，调试极其方便，但性能和功能都比较有限。
|
||
|
||
为了直观感受这些差异，看一个 STOMP 发消息的例子——你能直接用 `telnet` 打出来：
|
||
|
||
```
|
||
CONNECT
|
||
accept-version:1.2
|
||
host:localhost
|
||
|
||
^@
|
||
```
|
||
|
||
```
|
||
SEND
|
||
destination:/queue/orders
|
||
content-type:text/plain
|
||
|
||
Hello from telnet!
|
||
^@
|
||
```
|
||
|
||
> `^@` 是 STOMP 的帧分隔符（NULL 字节）。整个协议就是"命令 + 头部 + 空行 + 体 + NULL"，人可以直接读写，这正是它的设计初衷。
|
||
|
||
### 协议演进趋势
|
||
|
||
消息协议的演进大致经历了三个阶段：
|
||
|
||
```mermaid
|
||
graph LR
|
||
Phase1["阶段1 私有协议 2000s 前"]
|
||
Phase2["阶段2 标准化探索 2003-2011"]
|
||
Phase3["阶段3 分化与云原生 2012 至今"]
|
||
Future["未来 协议互操作"]
|
||
Phase1 -->|"JMS 定义 API 规范, 但无线路协议"| Phase2
|
||
Phase2 -->|"AMQP 0-9-1 定义线路格式, Kafka 选择私有协议"| Phase3
|
||
Phase3 -->|"AMQP 1.0, OpenMessaging, NATS"| Future
|
||
```
|
||
|
||
1. **私有协议时代（2000s 前）**：每个 MQ 厂商各搞一套，JMS 虽然是规范但限于 Java 生态，且只定义 API 不定义线路协议（wire protocol），不同实现之间依然不互通。
|
||
2. **标准化探索时代（2003–2011）**：AMQP 0-9-1（2008）定义了线路层格式，让"一个客户端连多个 Broker"成为可能。但同期 Kafka（2011）反其道而行——选择私有协议换取极致吞吐，证明标准化并非唯一正确路线。
|
||
3. **分化与云原生时代（2012 至今）**：AMQP 1.0（2012）成为 ISO/IEC 标准，但它与 0-9-1 几乎是两个完全不同的协议，去掉了 Exchange 等抽象模型，改用 Link/Terminus——这种断裂导致迁移成本极高，业界采用缓慢。与此同时，NATS 以极简设计切入云原生微服务场景，OpenMessaging 则面向多云和 Serverless 探索新方向。
|
||
|
||
> [!question]
|
||
> OpenMessaging 是由阿里等中国厂商主导的协议标准。你觉得在消息中间件领域，中国厂商能否主导下一个通用标准？需要具备哪些条件？
|
||
|
||
### 如何选择协议
|
||
|
||
选协议本质上是选场景。几个判断维度：
|
||
|
||
- **需要 IoT/移动端？** → MQTT（轻量、离线消息）
|
||
- **需要企业级可靠投递？** → AMQP（确认机制、事务、灵活路由）
|
||
- **需要高吞吐流处理？** → Kafka 私有协议（性能无可替代）
|
||
- **需要云原生微服务通信？** → NATS（低延迟、无状态、部署极简）
|
||
- **需要快速调试或 WebSocket 场景？** → STOMP（文本协议、简单直观）
|
||
- **需要跨云厂商中立？** → OpenMessaging 或 AMQP 1.0
|
||
|
||
没有银弹，理解每种协议的设计意图，才能做出合理的技术选型。
|
||
|
||
## 关联笔记
|
||
|
||
- [[5-AMQP-协议]]
|
||
- [[6-MQTT-协议]]
|
||
- [[7-JMS-与-OpenMessaging]]
|