RocketMQ 消费模式详解：集群消费 (CLUSTERING) vs 广播消费 (BROADCASTING)

🚀 RocketMQ 消费模式详解：

集群消费 (CLUSTERING) vs 广播消费 (BROADCASTING)

在 RocketMQ 中，消费模式决定了消息如何被消费者处理。
RocketMQ 提供了两种核心消费模式：

• 集群消费（CLUSTERING）
• 广播消费（BROADCASTING）

它们在消息分发方式、消费语义、适用场景上完全不同。
正确理解并选择合适的消费模式，是构建高效、可靠消息系统的关键。

---

一、核心对比总览

特性	集群消费 (CLUSTERING)	广播消费 (BROADCASTING)
消费语义	点对点（P2P）	发布/订阅（Pub/Sub）
消息是否共享	❌ 每条消息只被一个消费者消费	✅ 每个消费者都收到所有消息
消费者关系	竞争关系（负载均衡）	广播关系（独立消费）
Consumer Group 作用	共享消费进度（Offset）	仅用于标识，Offset 存本地
是否支持重试	✅ 支持（进入 %RETRY% 队列）	❌ 不支持
是否支持顺序消费	✅ 支持	✅ 支持
典型场景	订单处理、任务队列	配置更新、缓存刷新

---

二、1. 集群消费（CLUSTERING）—— 点对点模式

✅ 定义：

多个消费者属于同一个 Consumer Group，共同消费一个 Topic，每条消息只被 Group 内的一个消费者处理。

类比：多个工人分拣一车快递，每人分几件，每件只被一人处理。

🔧 设置方式：

consumer.setMessageModel(MessageModel.CLUSTERING);

🔄 工作机制：

Producer → 发送消息到 Topic
   ↓
Topic 有 4 个 MessageQueue
   ↓
Consumer Group: order_processor（含 2 个实例）
   ↓
Instance-1 → 消费 Queue0, Queue1
Instance-2 → 消费 Queue2, Queue3
   ↓
每条消息只被一个消费者消费

✅ 核心特性：

特性	说明
负载均衡	Queue 被 Group 内消费者均分
高可用	某消费者宕机，其 Queue 由其他实例接管
消费进度（Offset）	存储在 Broker 的 __consumer_offsets 中，全局共享
支持重试	消费失败进入 %RETRY%{groupName} 队列
支持死信队列（DLQ）	重试失败后进入 %DLQ%{groupName}

🎯 适用场景：

• 订单处理系统
• 支付异步任务
• 邮件发送队列
• 批量数据处理

✅ 这是 RocketMQ 最常用的消费模式。

---

三、2. 广播消费（BROADCASTING）—— 发布/订阅模式

✅ 定义：

每个消费者都会收到 Topic 的所有消息，无论是否在同一 Consumer Group。

类比：公司群发通知，每个员工都收到完整消息。

🔧 设置方式：

consumer.setMessageModel(MessageModel.BROADCASTING);

🔄 工作机制：

Producer → 发送 1 条消息
   ↓
3 个消费者（即使在同一 Group）
   ↓
每个消费者都收到这条消息

✅ 核心特性：

特性	说明
全量消费	所有消费者独立接收全部消息
无负载均衡	不进行 Queue 分配
消费进度（Offset）	存储在消费者本地文件系统（~/.rocketmq_offsets/）
不支持重试	消费失败即跳过，无重试机制
不支持死信队列	无法进入 DLQ
适合轻量级通知	消息量不宜过大

🎯 适用场景：

• 配置中心推送新配置
• 缓存节点刷新本地缓存
• 节点状态同步
• 日志收集代理通知

✅ 适用于“状态同步”类场景，而非“任务处理”类。

---

四、集群消费 vs 广播消费：深入对比

1. 消息分发机制

模式	分发方式
CLUSTERING	消息按 Queue 分配，Group 内竞争消费
BROADCASTING	每个消费者独立拉取所有 Queue 的消息

2. Offset 存储位置

模式	存储位置	是否共享
CLUSTERING	Broker 端（远程）	✅ 所有实例共享
BROADCASTING	消费者本地磁盘	❌ 每个实例独立

⚠️ 广播模式下，重启消费者可能从上次 Offset 继续消费，但不同实例之间不一致。

3. 容错与重试

模式	重试机制	容错能力
CLUSTERING	支持，进入 %RETRY% 队列	高（失败可重试）
BROADCASTING	不支持	低（失败即丢弃）

4. 性能与扩展性

模式	并发能力	扩展建议
CLUSTERING	高（可扩容消费者）	增加消费者实例
BROADCASTING	低（每个实例全量消费）	避免过多消费者

⚠️ 广播模式下，消费者越多，网络和处理压力越大。

---

五、如何选择消费模式？

业务需求	推荐模式	理由
任务处理、异步执行	CLUSTERING	避免重复处理，支持重试
配置更新、缓存刷新	BROADCASTING	所有节点需同步状态
多系统接收同一事件	CLUSTERING + 多 Group	不同 Group 独立消费
日志分发	BROADCASTING 或 多 Group	根据是否需要全量决定
保证顺序消费	两种都支持	配合 MessageListenerOrderly

---

六、最佳实践建议

实践	说明
✅ 默认使用 CLUSTERING	适用于 90% 的业务场景
✅ 关键任务使用 CLUSTERING + 重试机制	保障可靠性
✅ 配置类通知使用 BROADCASTING	简单高效
✅ 避免在 BROADCASTING 模式下处理耗时任务	防止阻塞
✅ 监控 CLUSTERING 模式的消费延迟	使用 mqadmin consumerProgress
✅ BROADCASTING 模式下注意本地磁盘空间	Offset 文件可能积累

---

七、常见问题排查

问题	可能原因	解决方案
消费者不消费	模式设置错误	检查 MessageModel
重复消费	CLUSTERING 模式 Rebalance	做幂等处理
广播模式未收到消息	本地 Offset 过高	删除本地 ~/.rocketmq_offsets/ 目录
消费积压	消费者处理慢	扩容或优化逻辑
重试失败进入 DLQ	业务异常未修复	人工补偿或修复后重新消费

---

✅ 总结

消费模式	核心思想	一句话总结
集群消费 (CLUSTERING)	负载均衡，一条消息一个消费者	“任务分发，各干各的”
广播消费 (BROADCASTING)	全量通知，每个消费者都收到	“群发通知，人人有份”

🚀 最终建议：

• 任务处理、异步任务 → 用 CLUSTERING
• 状态同步、配置更新 → 用 BROADCASTING
• 多系统消费同一消息 → 用 CLUSTERING + 多 Consumer Group

掌握这两种消费模式，你就能灵活构建从任务队列到事件广播的各种分布式架构。