消息模型

本页结论：队列、发布订阅、分区日志、请求响应四种模型解决不同问题；选型第一步是确定需要的模型，而不是挑选产品。

四种基本模型

下面提供可切换的交互拓扑：选择模型查看参与方与消息流向，点「播放消息流」高亮一条消息的路径（静态示意，不连接真实 Broker）。

一条消息只被组内一个消费者处理；消费者越多，处理能力越强（RabbitMQ Queue / Kafka 同组消费者 / Pulsar Shared）。

生产者Queue / 分区消费者 A消费者 B

• 生产者 → Queue / 分区 （入队）
• Queue / 分区 → 消费者 A （二选一投递）
• Queue / 分区 → 消费者 B （二选一投递）

1. 竞争消费（Work Queue / Competing Consumers）

一条消息只被组内一个消费者处理，消费者水平扩展处理能力。

典型场景：任务分发、订单处理。关键语义：分发公平性、预取（Prefetch）、单条消息只成功处理一次（配合确认）。

2. 发布订阅（Pub/Sub）

一条消息被每个订阅各投递一次；订阅内部可以再竞争消费。

典型场景：事件广播。关键语义：每个订阅独立维护消费位置；新增订阅通常只能消费其建立之后的消息（日志型系统可回放除外）。

3. 分区日志（Partitioned Log / Event Stream）

消息追加写入分区，消费不删除数据，按游标（Offset/Cursor）推进，可任意回放。

典型场景：事件溯源、审计流、流处理上游。关键语义：分区内有序、消费组再均衡、保留期与回放。

4. 请求响应（Request/Reply）

借助消息通道完成一问一答，通常有临时回复队列或关联 ID。适合需要跨进程调用但不想直连的场景；不适合要求严格低延迟的同步调用。

保证成立的条件

• 竞争消费的“每条只处理一次”依赖消费确认 + 业务幂等（at-least-once 下重复投递是常态）。
• 发布订阅的“每个订阅都能收到”依赖各订阅自身的确认与重试配置。
• 分区日志的“可回放”依赖保留期（Retention）未被清理。

不保证什么

• 队列模型的“消费即删”不提供历史回放；不要把它当日志用。
• 日志模型的“高吞吐”不代表低延迟场景同样合适。
• 请求响应模式需要自行处理超时与关联，Broker 不提供 RPC 框架的完整语义。

常见误区

• 把 RabbitMQ 的 Topic Exchange（路由机制）与 Kafka 的 Topic（订阅通道+日志）当作同一概念。
• 认为发布订阅天然广播给“所有消费者”——实际单位是订阅，同一订阅内的多个消费者仍是竞争消费。

实验复现命令

npm run lab -- rabbitmq basic     # 竞争消费：发 3 收 3，单队列单消费者
npm run lab -- rabbitmq routing   # 三个独立订阅（队列）对同一交换机的不同路由

官方资料与版本说明

模型定义为中性描述；产品映射见 RabbitMQ 概念映射 与统一术语表。