---
tags:
  - MQ
create time: 2026-05-24 19:52
---

# MQ 消息协议总览

## 概述

消息协议是消息队列系统中 Producer、Broker、Consumer 之间的"通信语言"。不同的 MQ 产品使用不同的协议，协议的选择直接影响互操作性、性能和适用场景。本文梳理主流消息协议的设计定位与演进脉络。

## 正文

### 为什么需要消息协议

试想一个场景：你用 RabbitMQ 的客户端库去连接 Kafka，能成功吗？显然不能。因为它们"说的不是同一种语言"。消息协议就是定义客户端与 Broker 之间如何交换数据的规范——消息怎么编码、命令怎么发送、连接怎么建立、确认怎么回传，全都由协议约定。

协议存在的意义在于两点：**互操作性**和**标准化**。有了统一的协议，不同厂商的客户端和 Broker 可以互相通信；没有协议（或协议私有），就只能绑定在单一产品上。

> [!question]
> 如果你是一家公司的架构师，需要同时接入 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 |
| **OpenMessaging** | 跨语言跨平台标准 | 云原生、厂商中立 | 多云部署 | 阿里云 RocketMQ |
| **Kafka 私有协议** | 高吞吐流处理 | 追求极致性能，协议与实现强绑定 | 日志收集、实时流计算 | Apache Kafka |

> [!question]
> 观察这张表，你会发现"标准化"和"性能优化"之间似乎存在矛盾——Kafka 放弃了标准化却获得了极致性能。你觉得这种取舍合理吗？

### 协议的设计哲学差异

协议之间的差异不只是格式不同，背后是**设计哲学的分歧**：

- **AMQP** 走的是"标准化 + 丰富语义"路线。它定义了 Exchange、Queue、Binding 等抽象模型，Broker 承担了大量路由和过滤工作。好处是功能强大，代价是协议复杂。
- **MQTT** 走的是"极简 + 弱网适应"路线。协议报文最小只有 2 字节，支持 QoS 0/1/2 三级投递保障，专门为带宽受限的 IoT 设备设计。
- **Kafka** 走的是"性能优先"路线。它的私有协议直接操作文件系统的 offset，零拷贝传输，协议与存储引擎深度耦合。标准化反而会成为性能瓶颈。
- **STOMP** 走的是"简单可读"路线。纯文本协议，用 `telnet` 就能手动发送消息，调试极其方便，但性能和功能都比较有限。

### 协议演进趋势

消息协议的演进大致经历了三个阶段：

```mermaid
graph LR
    Phase1["阶段1: 私有协议"]
    Phase2["阶段2: 标准化"]
    Phase3["阶段3: 跨平台云原生"]

    Phase1 -->|"JMS 规范 Java 生态"| Phase2
    Phase2 -->|"AMQP 0-9-1 业界采用"| Phase3
    Phase3 -->|"AMQP 1.0 / OpenMessaging"| Future["未来: 协议互操作"]
```

1. **私有协议时代**：每个 MQ 厂商各搞一套，JMS 虽然是规范但限于 Java 生态，且只定义 API 不定义线路协议（wire protocol），不同实现之间依然不互通。
2. **标准化时代**：AMQP 0-9-1 的出现让 RabbitMQ 成为事实标准。协议定义了线路层格式，真正实现了"一个客户端连多个 Broker"的可能性。
3. **跨平台云原生时代**：AMQP 1.0 成为 ISO/IEC 标准，去掉了对 Broker 模型的强依赖；OpenMessaging 由中国厂商主导，面向多云和 Serverless 场景。

> [!question]
> OpenMessaging 是由阿里等中国厂商主导的协议标准。你觉得在消息中间件领域，中国厂商能否主导下一个通用标准？需要具备哪些条件？

### 如何选择协议

选协议本质上是选场景。几个判断维度：

- **需要 IoT/移动端？** → MQTT（轻量、离线消息）
- **需要企业级可靠投递？** → AMQP（确认机制、事务、灵活路由）
- **需要高吞吐流处理？** → Kafka 私有协议（性能无可替代）
- **需要快速调试或 WebSocket 场景？** → STOMP（文本协议、简单直观）
- **需要跨云厂商中立？** → OpenMessaging 或 AMQP 1.0

没有银弹，理解每种协议的设计意图，才能做出合理的技术选型。

## 关联笔记

- [[5-AMQP-协议]]